feat: add legacy storage key cleanup functionality

[joker23]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues
sdk-569

Describe the solution you've provided
- Introduced getLegacyStorageKeys method to as an optional internal option that could be configured per SDK.
- Updated LDClientImpl to support cleaning old persistent data based on the new option cleanOldPersistentData.
- Implemented getLegacyStorageKeys in Browser SDK so the feature is fully available there.
- Added a test to verify that old persistent data is cleaned while retaining current keys.

Additional context

Additionally I've added some refactors that would address the following:
- changing Flagstore + FlagUpdater classes to interface (starting SDK-1686) which saves us a few bytes
- Added a comment in LDClientImpl.ts to clarify that "override" changes are not being tracked as they are currently used only for debugging and not persisted. This may change in the future. (left over comment from a previous PR)

---

Note

Introduces optional removal of legacy persisted data and refactors flag management internals.

• New option: LDOptions.cleanOldPersistentData (validated in validators.ts); when enabled, LDClientImpl clears keys returned by internalOptions.getLegacyStorageKeys via platform storage with error-tolerant logging
• Browser support: BrowserClient provides getLegacyStorageKeys using getAllStorageKeys from platform/LocalStorage (filters ld:${clientSideId}:*)
• Platform util: Adds getAllStorageKeys() to LocalStorage.ts
• Refactors: Convert DefaultFlagStore and FlagUpdater classes to interface + factory (createDefaultFlagStore, createFlagUpdater); update usages in FlagManager, FlagPersistence, and tests
• Tests: Add coverage for legacy key cleanup and update existing tests to new factories; minor comment clarifying that "override" changes are not tracked in inspectors

^{Written by Cursor Bugbot for commit 8289e33. This will update automatically on new commits. Configure here.}

[github-actions]

@launchdarkly/browser size report
This is the brotli compressed size of the ESM build.
Compressed size: 171128 bytes
Compressed size limit: 200000
Uncompressed size: 798044 bytes

[github-actions]

@launchdarkly/js-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 25394 bytes
Compressed size limit: 26000
Uncompressed size: 124693 bytes

[github-actions]

@launchdarkly/js-client-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 18730 bytes
Compressed size limit: 20000
Uncompressed size: 96409 bytes

[github-actions]

@launchdarkly/js-client-sdk size report
This is the brotli compressed size of the ESM build.
Compressed size: 23295 bytes
Compressed size limit: 25000
Uncompressed size: 80935 bytes

[kinyoklion]

I am not very comfortable with this approach to using local storage. While it can work it can have pitfalls if someone has, for example, done some monkey patching and only uses the local storage API instead of using it as POD.

I think we should use .length and .key()

const keys = [];
for (let i = 0; i < localStorage.length; i++) {
  keys.push(localStorage.key(i);
}
return keys;