compass build scopes itself with systemd-run, which the sandbox cannot reach

compass build caps the compile step in a memory-limited slice by wrapping it in a raw systemd-run --user --scope. Inside the DSH file sandbox that call fails before anything compiles:

Failed to connect to user scope bus via local transport: No data available

The scope needs the private user-manager socket at $XDG_RUNTIME_DIR/systemd/private, which the sandbox does not expose.

The rest of compass already solved this. systemctl_bus.py exists because "inside a bubblewrap" the user manager "answers busctl over the D-Bus session bus" rather than over the private socket, so every systemctl --user call goes through it. The build's scope is the one place that calls the raw tool instead, and that is what breaks.

The result is a detection that disagrees with the action it authorises. _has_user_systemd() probes with systemctl_bus.run(["show-environment"]), which succeeds through the shim, so compass decides to scope the build; the raw systemd-run that follows then cannot connect. Measured in the sandbox:

Two candidate fixes. Route the scope through the shim, if busctl can start a transient scope at all. Or make the check probe what it is about to do, and run the build unscoped when it cannot – the memory cap is a convenience, and an uncapped build beats no build.

Until then the workaround is an escalated shell, which is an approval prompt on every build and one an agent should not have to raise.

• projects/ores.compass/src/compass.py, the systemd-run invocation in the build pillar.
• projects/ores.compass/src/systemctl_bus.py, the shim and the reason for it.
• projects/ores.compass/src/compass_claude.py, _has_user_systemd() and the slice deployment.

• doc/agile/product_backlog/inbox/settings_build_reverts_bare_stash_test.org, another build-side effect that only shows up when the build is run.