sandbox-preflight reports a block for sessions it cannot see: hardcoded workspace-write, Windows acl-runner always false (shipped in #610) #615

Symptom

The preflight merged in #610 (squash 7eae271c, Fixes #607) reports a blocked sandbox for sessions it cannot see, and the instruction it feeds then stops a working session. #607 was closed as completed; this tracks the defect that shipped with it.

Reviewer's INC on the PR (#610#issuecomment-6314730587, 11:24:37Z) was posted before the merge (11:25:23Z) and none of its three items is in the merged code: main's .github/scripts/sandbox-preflight.mjs is byte-identical to the reviewed tip e7ccdd06 (sha256 of the file, 4832 bytes). Found by the reviewer while reviewing the PR; no code changed here.

Evidence (reproduced at the reviewed tip, unchanged on main at 81c708d0)

$ node .github/scripts/sandbox-preflight.mjs
sandbox-preflight: workspace-write is UNAVAILABLE: no usable sandbox backend (bubblewrap missing or not runnable; Landlock not enabled). Every shell call will be refused with SANDBOX_UNAVAILABLE. … Unlock: …
$ echo hello && id -u
hello
10001

The session that ran it was on danger-full-access (bash works, as shown), yet the line says every shell call will be refused. AGENTS.md's new paragraph then says: if it is blocked, report one line and do not retry shell calls — so an agent on danger-full-access, or any Windows session, is told to stop doing shell work that works.

Cause

• .github/scripts/sandbox-preflight.mjs:18 — export const MODE = 'workspace-write' is hardcoded; the script always answers for a mode the caller may not be on, and no tool exposes the session's actual DSH file policy to the plugin.
• .github/scripts/sandbox-preflight.mjs:62 — 'acl-runner': () => false: the Windows restricted-token runner cannot be probed from here, but false is reported as blocked, and :64 makes it the only candidate on Windows, so every Windows session reads as blocked even when the runner works.
• .github/scripts/sandbox-preflight.mjs:76 — describe() interpolates the module constant UNLOCK instead of result.unlock.

Fix (mechanical, as proposed on the PR)

1. Take the mode from an argument/env (--mode <tier> / FLYBOT_SANDBOX_MODE) and answer for that mode only; with no mode given, print the conditional wording ("if this session is on workspace-write, every shell call is refused").
2. Give backends a third state (unknown) for acl-runner; usable stays false, but the exit code must separate proven blocked (3) from cannot probe (new code), and AGENTS.md / docs/sandbox.md say "do not stop on unknown".
3. describe(result) reads result.unlock; resolveOnPath checks statSync().isFile() so a directory named bwrap reads as missing; docs/sandbox.md "it print" → "it prints".

Tests, all red without the change:

• --mode danger-full-access (or the env) → exit 0 and no "will be refused" line;
• --mode workspace-write with no backend → exit 3 (the existing test);
• acl-runner unknown → exit code for unknown, JSON carries unknown: true;
• a directory named bwrap on a fake PATH → bwrap: false.

Acceptance

On a danger-full-access session the preflight never tells the agent to stop; on Windows it reports unknown, not blocked; an agent following AGENTS.md cannot conclude "blocked" from a probe that only tested one mode.

Notes

• The unlabelled risk:T* on fix: preflight the sandbox backend and name a blocked session (#607) #610 stays a controller matter; this issue is the behaviour, not the label.
• If the fix-forward is chosen (rather than a revert of 7eae271c), this is its issue: one issue, one PR.
• Related: fix: preflight the sandbox backend and name a blocked session (#607) #610, New Bot sessions with workspace-write have no usable sandbox backend and stall silently #607 (closed), Rule says the controller sets risk:T*, but risk-tier.yml is report-only and never writes labels #609 (labels written by the controller).