fix(executors): carry user-bus transport env into the systemd-run wrapper

[drewstone]

What

scoped-host wraps host spawns in systemd-run --user --scope, and systemd-run resolves the user manager through XDG_RUNTIME_DIR / DBUS_SESSION_BUS_ADDRESS in its own environment. A backend with a strict child-env allowlist (prime strips both by design) therefore broke the wrapper itself: systemd-run exited 1 with Failed to connect to bus: No medium found, and the exit was misattributed as prime exit 1. The availability probe passes ($XDG_RUNTIME_DIR/systemd/private exists) so the fallback never fired.

Fix: re-inject the two transport vars from the bridge's own env into the wrapper invocation. Transport plumbing, not credentials — the payload ignores them.

Proof (live, real model)

Found and fixed during the first live prime e2e. After the fix, on this host through the full path (bridge → scoped-host systemd-run → nix-built prime-agent 0.7.0 → IPython kernel → z.ai glm-5.2):

• Kernel-execution task: Collatz record below 100000 → 77031 / length 351 and sha256 prefix → f8b225cf1905850c — both independently recomputed locally, exact match; 2 model requests, 25,599 in / 471 out tokens; trace carries the kernel tool-call spans.
• AgentProfile run (harness: "prime", appendSystemPrompt, inline skill): deliberately-wrong expected hash was refuted from real execution (VERIFIED-FALSE, recomputed value matches local), profile marker line present in output — profile materialization proven end-to-end.
• tsc --noEmit clean.

Known follow-up (named, not smuggled)

A systemd-run that starts and exits non-zero is still attributed to the backend CLI (the documented per-invocation fallback only catches spawn errors). Distinguishing wrapper-failure stderr signatures and degrading to hostSpawner is a separate, small change.