Harden the default sandbox working directory against DLL/executable planting

### Description of the task

Follow-up from review feedback on #674 (thread on `appcontainer_runner.rs:944`).

Since #674, a Windows ProcessContainer sandbox with no explicit `process.cwd` starts in the first granted `readwritePaths` entry — a directory the sandboxed process can itself **write to**. On Windows the current directory participates in the DLL search order for the child and in image resolution for unqualified helper processes it spawns, and the launchers apply no DLL-search hardening today (the only mitigation configured disables Win32k — `src/backends/appcontainer/common/src/appcontainer_runner.rs`, `process_mitigation.rs`).

This matters most because the grant is often **shared across runs**: the SDK temp-files helper returns the existing shared `%TEMP%` root rather than a per-run directory (`sdk/node/src/policy.ts`, `src/core/mxc_engine/src/policy.rs`). An earlier sandbox can plant a payload that a later sandbox — with different secrets, capabilities, or network access — loads under the later identity.

Scope note: the *initial* image is not selected via `lpCurrentDirectory` (both launch paths pass a null `applicationName`), so the exposure begins once the child is running.

Expected outcome — one or both of:

1. Prefer a per-execution private directory over a reusable writable grant when defaulting the cwd.
2. Enable safe DLL search / image-load mitigations on the launch (e.g. `PROCESS_CREATION_MITIGATION_POLICY_*` image-load flags) for both the AppContainer and BaseContainer launch paths.

### Additional context

- Default cwd resolution now lives in `src/backends/appcontainer/common/src/working_directory.rs`.
- Per-backend behavior is documented in `docs/schema.md` under "Working Directory".