Feat: Seed remote feature flag controller with default flags

[Cal-L]

Explanation

This is part of an effort to keep the RemoteFeatureFlagController as the source of truth for feature flags. As part of that effort, we've added a new optional constructor arg named defaultFeatureFlags, which will be provided by the platform apps. Under the hood, the controller will account for these flags when processing the effective flags that the consumers will use. The order of priority for the flags are - default flags > remote flags > override flags.

References

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 how effective flags are computed and persisted across upgrades and offline fetch failures; behavior is heavily tested but affects a widely used controller path.

Overview
Remote feature flag layering — Apps can pass optional defaultFeatureFlags (not persisted) into RemoteFeatureFlagController; Wallet exposes the same via instanceOptions.remoteFeatureFlagController.defaultFeatureFlags.

Persisted processed remote — State gains processedRemoteFeatureFlags (persisted) as the remote layer after threshold/version processing. Effective remoteFeatureFlags are always derived via #getEffectiveFeatureFlags: defaults < processed remote < local overrides. Overrides and cache updates write through that helper instead of mutating remoteFeatureFlags directly.

Upgrade and fetch behavior — If processedRemoteFeatureFlags was never saved, cache is invalidated to force a refetch; pre-upgrade installs still use the old persisted remoteFeatureFlags for first paint while defaults apply underneath. When a fetch fails in that state, the controller can hydrate processedRemoteFeatureFlags from persisted rawRemoteFeatureFlags without advancing cacheTimestamp so retries still happen.

Tests cover defaults, precedence, migration, failed-fetch hydration, and threshold edge cases (no matching group, nameless threshold entries).

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

[Cal-L]

This persisted state is the processed version of REMOTE feature flags, excluding defaults and overrides. Used for flag reconstruction on controller creation, preventing the need for a deconstruction.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ 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 8576196. Configure here.}

[Cal-L]

Ability for platforms to provide feature flag defaults

[Cal-L]

Force refetch if processed remote feature flags do not exist

[Cal-L]

Prioritize feature flags in this order