chore: Fix broken override feature on the remote feature flag controller

[Cal-L]

Explanation

This PR fixes issues related to incorrectly setting and removing flags based on overrides. Prior to this change, the persisted remoteFeatureFlags needed to cleaned prior to effective flag reconstruction, which meant overrides needed to be removed first. This led to broken behavior where flags were completely removed instead of falling back to remote feature flags. We're now leveraging the existing rawRemoteFeatureFlags to reconstruct effective flags. To make this happen, we also removed metametrics ID redacting. For context, there's there's a scenario where QA/PMs/Devs can provide their own metametrics IDs for specific device targeting. That being said, the IDs do not belong to users.

References

Fixes https://consensyssoftware.atlassian.net/browse/MCWP-774

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Changes feature-flag precedence and persistence semantics (overrides, raw metaMetricsIds in state/logs); incorrect init timing could yield stale flags until fetch.

Overview
Adds RemoteFeatureFlagController.init(), which re-runs version/threshold processing on persisted rawRemoteFeatureFlags (no network fetch) and refreshes effective remoteFeatureFlags, threshold cache, and featureFlagThresholdGroups. Consumers should call init() after restore (e.g. via Wallet.init()).

Override fix: On startup the controller no longer tries to infer the remote layer by stripping override values from persisted effective flags. It keeps a private #processedRemoteFeatureFlags layer and merges defaults → processed remote → local overrides when setting or clearing overrides, so removeFlagOverride restores the real remote value even when it matched the override.

Raw flag storage: redactMetaMetricsIds is removed; rawRemoteFeatureFlags (and debug/state log derivation) retain metaMetricsIds so explicit QA targeting can be re-applied after restart. Processed remoteFeatureFlags still resolve to scalar values without leaking IDs when a match is selected.

Processing refactor: #updateCache and init share #processRemoteFeatureFlags, which now returns the full reconciled threshold cache in one place.

^{Reviewed by Cursor Bugbot for commit 55e0db6. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 96f169a. Configure here.}

[cursor]

Init drops explicit targeting on upgrade

Medium Severity

init reprocesses persisted rawRemoteFeatureFlags, but existing installs still have those raw entries with metaMetricsIds stripped by older builds. Explicit QA targeting then falls through to hash selection and overwrites the previously correct effective value. Because cacheTimestamp is left intact when the client version is unchanged, updateRemoteFeatureFlags can skip a refetch for up to the full cache interval, leaving targeted users on the wrong variant.

Additional Locations (1)

• packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts#L380-L398

 

^{Reviewed by Cursor Bugbot for commit 96f169a. Configure here.}

[Cal-L]

I'm thinking of leaving this alone for the following reasons:

• Only affects devs who are still using the metametrics IDs targeting in Launch Darkly
• Would require persisting another state for triggering a force refetch on this controller version
• After 24 hrs and calling updateRemoteFeatureFlags will resolve this