bug(supervisor): live filesystem policy changes are reported loaded but not applied on Windows #5326

User Story

I work on OpenShell's native Windows support and run the gateway with the built-in MXC driver on Windows 11 x64. Our QA found that adding a read-write folder to a running sandbox with openshell policy set --wait reports the new version as loaded, and sandbox get lists the folder, but the workload still cannot write to it. Anyone who changes a running Windows sandbox's filesystem policy is told the change is in force when it is not.

Problem Statement

This is the windows branch counterpart of #5041, which #5234 fixes on main. The gateway accepts a live policy update that only adds filesystem paths (validate_filesystem_additive in crates/openshell-server/src/grpc/validation.rs). The supervisor's poll loop then reloads only the network policy and reports the revision as loaded (run_policy_poll_loop_with_client in crates/openshell-supervisor/src/lib.rs). On Windows the MXC driver maps filesystem grants into the container only when the sandbox is created, so the running workload never receives the added path.

#5234 cannot be cherry-picked to windows: its change is in crates/openshell-supervisor/src/config_runtime.rs, which windows does not have; the poll loop is still in lib.rs.

Impact / Why This Matters

The CLI, policy list and policy get all report a policy that is not enforced. An operator who grants a folder to an agent mid-session sees "loaded", and the agent keeps failing with access denied, with nothing pointing at the cause.

Acceptance Criteria

• On windows, a live policy update whose filesystem section differs from the one applied at sandbox start is reported as failed, with a message that the sandbox must be recreated, as fix(supervisor): reject live filesystem policy changes that cannot take effect #5234 does on main.
• openshell policy set --wait exits non-zero for such an update.
• Network-only updates, including ones that list the same filesystem paths in a different order, still load.

Reproduction Steps

1. On Windows x64, build the windows branch and start the gateway with the built-in MXC driver (OPENSHELL_COMPUTE_DRIVER=mxc, backend = "process_container", allow_driver_config = true). Register and select it with openshell gateway add and openshell gateway select.

2. Create folders C:/work/b63/A and C:/work/b63/B, and save this policy as hr1.yaml:

   version: 1
   filesystem_policy:
     include_workdir: false
     read_only: []
     read_write: ['C:/work/b63/A']

3. Create a detached sandbox with that policy and a workload that keeps writing to A and tries to write to B (I used a cmd.exe for /L loop through --driver-config-json).

4. Run openshell policy set <name> --policy hr2.yaml --wait, where hr2.yaml is the same policy with read_write: ['C:/work/b63/A', 'C:/work/b63/B'].

5. Wait 25 seconds and check whether B contains the workload's file.

Actual: step 4 prints Policy version 2 loaded (active version: 2) and exits 0; policy list shows version 2 as Loaded and policy get shows Status: Effective. In step 5 the workload is still running, and B stays empty. A new sandbox created with both folders writes to B within seconds.

Expected: step 4 reports version 2 as failed and exits non-zero.

Environment

• OpenShell: openshell 0.1.5-dev.40+g5b9e5b91a (windows branch at 5b9e5b9)
• OS: Windows 11 Enterprise Insider Preview x64, build 28020, native
• Deployment: gateway with the built-in MXC driver, backend = "process_container", plaintext gateway on loopback

Logs

$ openshell policy set b63 --policy hr2.yaml --wait --timeout 60
✓ Policy version 2 submitted (hash: 91b0a1391613)
✓ Policy version 2 loaded (active version: 2)