Telemetry consent path has no automated coverage in release builds

### Description of the task

The telemetry consent path has automated coverage only in debug builds.

`tests/scripts/run_telemetry_consent_smoke_test.ps1` isolates the consent store via `MXC_TEST_LOCALAPPDATA_OVERRIDE`, and that override is compiled out of release builds by design (so a shipping binary cannot be pointed at an attacker-chosen consent store). The consequence is that the release build of the consent path — resolving `%LOCALAPPDATA%`, reading, writing, and the fail-closed parsing — is never exercised by CI. A release-only regression, for example a `#[cfg]` divergence or a difference in how the store path is resolved without the override compiled in, would ship undetected.

Consent gates whether MXC collects anything at all, so an untested release path is a privacy risk rather than merely a coverage gap.

Possible approaches, in rough order of preference:

1. Add a release-safe end-to-end test that runs `wxc-exec.exe --telemetry-consent-*` under a genuinely separate Windows user profile (or a redirected `USERPROFILE`/known-folder), so no test-only override is needed and the real path resolution is exercised.
2. Keep the override compiled into release but require an additional signed/CI-only opt-in, so the isolation cannot be triggered by an ordinary end user.
3. Accept debug-only coverage but add a build-time assertion that the release and debug store-path resolution share a single code path, so the two cannot drift.

### Additional context

Noted in `docs/telemetry/telemetry-consent-design.md` §12 under "Known gaps". Related: the consent design and store layout are described in the same document, §4 and §5.