Share the telemetry-consent test harness between wxc_common and mxc_ffi #690

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.