Function probe_scope 

pub fn probe_scope(
    required: bool,
    limits: &HostResourceLimits,
    workdir: &Path,
) -> ScopeProbe

Answers “would a launch get its cgroup scope here, and would the declared io.max ceiling apply on it?” by doing what a launch does, against a throwaway cgroup created and removed inside this call: [delegated_base], then the scope directory through the same [create_scope_dir] [prepare_scope] calls, then the io.max write.

The diagnostic half of [prepare_scope], for mur run --explain-scope and mur doctor, which run before any workdir exists and before any session is staged. required is requires_process_bounding for the capsule: without it nothing is attempted and both answers are not-required, the reports a launch writes for such a capsule. A failure carries the reason E-RUN-012 prints, so --explain-scope and the refusal word it identically.

Inferring the io.max answer from “is the io controller delegated” is wrong: the write can fail for a device the block layer will not accept (tmpfs, overlayfs, a device-mapper stack) on a host whose io controller is delegated perfectly well. Only performing the write answers it.

workdir need not exist. The device is resolved from its nearest existing ancestor, so the probe names the device a launch would use without creating anything.

Off Linux both answers are not-required. Whatever the outcome, the throwaway directory does not survive the call. Never run at launch: a launch learns the same answer from [prepare_scope].