Share the telemetry-consent test harness between wxc_common and mxc_ffi

### Description of the task

`src/ffi/mxc_ffi/src/lib.rs` carries its own copy of the telemetry-consent test harness — a `CONSENT_ENV_LOCK` mutex and a `LocalAppDataGuard` that redirects the consent store to a temp directory — duplicating the equivalent harness in `src/core/wxc_common/src/telemetry/consent.rs`.

This is structural rather than an oversight: `wxc_common::telemetry::consent::test_support` is `#[cfg(test)] pub(crate)`, so it is not compiled into `wxc_common` when that crate is built as a dependency, and `mxc_ffi` therefore cannot reference it.

Sharing it requires exposing the harness behind a cargo feature:

1. Add a `test-support` feature to `wxc_common`.
2. Gate `telemetry::consent::test_support` on `#[cfg(any(test, feature = "test-support"))]` and make it `pub` rather than `pub(crate)`.
3. Add `wxc_common = { workspace = true, features = ["test-support"] }` to `mxc_ffi`'s `[dev-dependencies]`.
4. Delete the duplicate harness from `mxc_ffi` and re-point its consent tests at the shared one.

The feature must stay off by default so the harness never reaches a shipping build.

### Additional context

Raised as a Low finding during the adversarial review of the telemetry consent work, and noted again in `docs/telemetry/telemetry-consent-design.md` §12 under "Known gaps". Test-only scaffolding, no shipped behavior at risk — but it is duplicated logic across crates, which the consent work otherwise set out to eliminate.