Windows sandbox does not deny reads of cloud credential stores

[euxaristia]

Context

PR #660 added default deny-read rules so sandboxed commands cannot read well-known credential stores (~/.aws, ~/.config/gcloud, ~/.azure, and the file GOOGLE_APPLICATION_CREDENTIALS points to). The rules are injected at permission profile construction (credentialDenyReadPaths in internal/sandbox/profile.go) and enforced by the seatbelt backend on macOS (file-read* deny rules) and the Linux helper (unreadable binds).

Windows is deliberately exempted, so on Windows a sandboxed command can still read those credential files under the read-all workspace posture.

Why Windows was skipped

Windows deny-read is implemented via ACL deny entries applied against capability SIDs (planWindowsDenyReadPaths / windowsReadDenyCapabilitySIDs in internal/sandbox/windows_acl.go). Making the profile DenyRead list non-empty by default has two side effects:

1. windowsReadDenyCapabilitySIDs stops returning nil, which moves the runner off the WRITE_RESTRICTED token path that fix(sandbox): use WRITE_RESTRICTED token when no DenyRead paths are configured #658 introduces for the no-deny-read case. The unelevated tier depends on that path; the full restricted-token path has a history of commands silently exiting 1 when unelevated.
2. The ACL deny entries mutate filesystem ACLs on the user's real credential directories, which is a heavier and more persistent intervention than the process-scoped seatbelt/bwrap rules on the other platforms, and needs elevation in some configurations.

What needs deciding

• Whether default credential deny-read on Windows should wait for the token/ACL model to settle (fix(windows): add Users and Authenticated Users SIDs to restricted token SIDs #640, fix(sandbox): use WRITE_RESTRICTED token when no DenyRead paths are configured #658 are in flight), or whether a scoped mechanism exists that does not flip the token selection.
• Whether ACL-based deny on real user directories is acceptable at all as a default, given it outlives the sandboxed process.
• Whether the interim mitigation (env scrubbing of provider keys and GOOGLE_APPLICATION_CREDENTIALS, which does apply on Windows) is enough until then.

Pointer

The exemption and rationale are documented on credentialDenyReadPaths in internal/sandbox/profile.go ("Windows is skipped" comment). Remove the runtime.GOOS gate there once a Windows mechanism lands.