[t-kalinowski]

On Linux, sandbox rules for missing read-only or denied paths can create empty mount targets on the host that remain after forced termination. Add read_only_if_exists and deny_if_exists filesystem options for execution and dependency preparation, including the R configuration API, so users can restrict existing paths without creating missing ones.

These rules apply only to paths that exist when the sandbox policy is selected. Missing paths keep their parent permissions: if created later, even by the host, they can remain readable and writable. Existing paths receive the usual read-only or deny restrictions. The workspace profile and ordinary read_only and deny rules retain their protection of missing paths.

Internally, Console resolves conditional rules before native runner handoff and preserves both empty and nonempty lists through configuration export. Public acceptance checks cover home expansion for both conditional rule types in worker and dependency-preparation policies. The pinned runner is unchanged.

The native Windows test client collects cell output through completion before dependent requests; input prompts and loop readiness use an explicit running-state expectation. A public R startup checkpoint reproduces the early-output race and verifies the complete output before Python is submitted. The shared transcript collector also preserves the final [done] marker across polls for combined control-and-cell calls and later continuations. A gated native R startup scenario verifies the exact prefix and completion as separate responses. These fixture changes leave production package defaults and interrupt deadlines unchanged.

On macOS, the conditional-filesystem changes passed 37 focused cases across 38 executions, including configuration export, path expansion, existing-path permissions, relay startup, and replacement startup; one Linux-only filename case was skipped. The R public configuration suites passed 101 expectations. Formatting, git diff --check, and scripts/check passed. The path-expansion failures and early-output busy rejection have local red/green evidence. The portable startup, late-error, explicit busy-rejection, input/interrupt, and SQLite callback sequences were exercised locally on macOS. Native Windows and Linux were not run locally for the completion repair.

The hosted Windows runner does not provide MXC, so native Windows sandbox execution remains unverified. Hosted checks for the current head are pending.

The controlled-completion repair was reproduced through the public native-startup scenario. On this branch, its three focused cases passed across five macOS direct/Seatbelt executions, including the gated native-startup response, replacement input, and a combined requirements/restart call. Formatting and diff checks passed; scripts/check passed at a409d07eb, and the final deadline refinement passed the gated native-startup case. Current Linux and Windows validation of that shared fixture repair is pending.

Related to #181.