Make the Windows ProcessContainer tier deterministically selectable for e2e coverage

### Description of the task

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

The Windows ProcessContainer tier (BaseContainer Tier 1 vs AppContainer+DACL Tier 2/3) is **not** independently selectable from a config: `dispatcher.rs` hardcodes `prefer_base_container = true` and derives the tier purely from host capability. The `MXC_FORCE_TIER` seam is `cfg(test)`-only, so it has no effect on the production `wxc-exec.exe` that the e2e suite invokes.

Consequence: on a BaseContainer-capable host — i.e. typical Windows 11 CI — the AppContainer+DACL launch path is unreachable from e2e, and a regression in it passes the ProcessContainer e2e suite unnoticed. "Run them on both a BaseContainer-capable and a downlevel host" is only a real strategy if such a lane exists and is required, and today neither is the case.

Expected outcome — either:

1. Expose a non-`cfg(test)` tier override (an undocumented `--force-tier` flag, or a config property) so a single capable host can deterministically exercise both tiers; or
2. Add a required downlevel lane and assert in CI that each tier actually ran.

### Additional context

- Tier selection: `src/backends/appcontainer/common/src/dispatcher.rs`, `fallback_detector.rs`.
- E2E suite affected: `src/testing/wxc_e2e_tests/tests/e2e_processcontainer_characterization.rs`.
- Partial mitigation already landed in #674: the cwd launch-argument mapping both tiers use was extracted into the shared, pure `appcontainer_common::working_directory`, which is unit-tested on every lane. That covers tier-independent logic only — anything genuinely tier-specific remains exposed.