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

Low Risk
Backward-compatible optional API; merge logic is centralized and covered by new tests, with no auth or persistence changes.

Overview
Adds an optional defaultFeatureFlags constructor option so platform apps can supply client-side defaults that are not persisted and sit below processed remote flags and local overrides.

Effective remoteFeatureFlags are now built through #getEffectiveFeatureFlags (defaults → processed remote → localOverrides) on init, after remote fetch, and when setting or clearing overrides—so defaults still apply for keys missing from the server and reappear when an override is removed with no remote value.

The wallet initialization path accepts instanceOptions.remoteFeatureFlagController.defaultFeatureFlags and forwards it to the controller.

^{Reviewed by Cursor Bugbot for commit 074d2dd. 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.

[davidmurdoch]

preventing the need for a deconstruction.

hm. my full time job right now is pretty much just removing persisted state that can be derived from other state. is that what this is?

[Gudahtt]

Could you elaborate on what this is for? remoteFeatureFlags is already the "processed" flags. What do you mean by "preventing the need for a deconstruction"?

[Cal-L]

@davidmurdoch @Gudahtt I think I made these changes more complex than needed. I ended up removing this field and simplified the PR to just intake a defaultFeatureFlags arg. The state in question is no longer relevant.

[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 a77816d. Configure here.}