security(sandbox): handle OS sandbox unavailable on Windows and Linux (no bwrap)

[ZhuchkaTriplesix]

Summary

Security review (0.4.11) found that database-driver extensions can run without OS-level sandbox in two cases:

• Windows: SandboxLaunchCommand sets usesOsSandbox: false (soft isolation until AppContainer helper lands).
• Linux: when bwrap is not available, launch falls back to direct plugin execution with usesOsSandbox: false.

A malicious or compromised extension/driver installed locally could then access the full user session (filesystem, network beyond policy, etc.).

Affected code

• lib/core/extensions/sandbox/sandbox_launch_command.dart (lines 64–65, 92–98)
• lib/core/extensions/sandbox/sandbox_process_runner.dart

Current mitigations

• SandboxPolicy validates manifest capabilities before install.
• Preview-only gate blocks drivers without process sandbox.
• Credentials injected via stdio RPC, not argv (SandboxSecretGuard).

Proposed fix

Pick one or combine:

1. Fail-closed: refuse to launch process-sandbox drivers when OS sandbox wrapper is unavailable; show actionable UI (install bwrap / unsupported platform).
2. Explicit consent: require user confirmation when usesOsSandbox == false, with clear risk wording.
3. Windows: track AppContainer / Job Object hardening and re-enable usesOsSandbox: true when ready.

Acceptance criteria

• No silent unsandboxed launch for SandboxEngine.process drivers without user-visible decision or hard block.
• Linux without bwrap: documented behavior + tests.
• Windows: documented limitation or improved isolation path with issue link.

Severity

High — architectural / platform limitation with direct impact on extension trust model.

Context

Found during post-0.4.11 security review. Related: Block E sandbox work, Marketplace 0.5.0.