feat(platform): add the metamask-extension overlay for feature-flags

[MajorLift]

Motivation

The feature-flags skill in #147 ships with a mobile overlay only, so an agent working in metamask-extension gets the shared skill and no client specifics.

Writing that overlay by transposing mobile's API would have produced something mostly right and wrong where it matters. The extension's helper is a direct port of mobile's, and shared/lib/remote-feature-flag-utils.ts:7 says so in its own header, so the exported names do match. Three things do not.

The version basis inverts mobile's warning. Mobile's overlay says the comparison is against the native binary version, not package.json. The extension resolves APP_VERSION from packageJson.version. Same symbol, opposite source, and the mobile sentence is actively misleading in this repo.

Two modules export the same three names with different semantics. shared/lib/remote-feature-flag-utils.ts and shared/lib/feature-flags/version-gating.ts both export hasMinimumRequiredVersion, validatedVersionGatedFeatureFlag and VersionGatedFeatureFlag. The second types minimumVersion as string | null and does not unwrap progressive-rollout wrappers. An import of either name compiles against either module, which is the trap a reader of the mobile overlay walks into.

getBooleanFeatureFlag is the house entry point, not mobile's. Counting invocations outside tests and outside the defining modules: 17 against 6. It takes the fallback as a required second argument rather than a trailing ?? localFlag.

Overview

Adds domains/platform/skills/feature-flags/repos/metamask-extension.md. Based on #147's branch, so it should merge after it.

Sections: the canonical API and the two-module collision, requirements, adding a flag, testing, what the extension does not have, and what it has that mobile does not.

Five things the mobile overlay covers have no extension counterpart and are named as absent rather than invented: the native binary version, multi-version { versions: {...} } flags, a central FeatureFlagNames registry, OVERRIDE_REMOTE_FEATURE_FLAGS, and a useRemoteFeatureFlag hook. Each was established with a positive control on the same search shape.

Showcase

No trial run. The evidence is that every symbol and path named was read from the repository, with the file it came from recorded.

Two things a reviewer should settle rather than inherit:

• Which of the two same-named modules is canonical is not written down anywhere. No ADR, no lint rule. The overlay recommends remote-feature-flag-utils on importer count (13 production files against 4), recency and wrapper support, and says explicitly that this is a preference rather than repo policy.
• Whether getBooleanFeatureFlag's dominance is a decision or accretion is likewise unrecorded.

Separate defect, found on the way and not fixed here: domains/testing/skills/ab-testing/repos/metamask-extension.md:78 on main tells readers to use FixtureBuilder.withRemoteFeatureFlags(...). That method does not exist. The string appears twice in metamask-extension, both inside doc comments in test/e2e/feature-flags/feature-flag-registry.ts. The real method is withRemoteFeatureFlagController, at test/e2e/fixtures/fixture-builder-v2.ts:428. This overlay names the real one.