fix(rum): keep remote settings across releases of the application

[Fiona2016]

Problem

The remote settings cache in localStorage was keyed by site | applicationId | env | version, with version being the application's own version. Every deploy therefore started with no entry. Each visitor's first session on the new release was drawn on the init settings and carried no _dd.configuration.rc_version. The fetch that session triggered only applied to the session after it.

Change

• buildStoreKey no longer includes the application version, so the settings stored by one release are read by the next. This matches the iOS SDK, whose cache key leaves the application version out for the same reason.
• Releases of one site live at the same time share the entry. That is right as long as they are given the same settings. If they ever are not, the shared entry is still the latest decision on record, and the fetch every page makes stores its own release's answer for its next draw.
• app_version is still sent on the config request.
• Entries written by earlier builds keep the version in their key, so they are no longer read. The existing age-based sweep removes them after two days. The first session after upgrading the SDK uses the init settings once.
• Comments on the key, the draw-record key and the sweep are updated to match.

Verification

• yarn test:unit: 3189 passed.
• New tests:
  • the key is the same across application versions;
  • a value fetched under one release is read by the next.
• Negative control: with the version put back into the key, exactly those 2 tests fail.

Supersedes #47.

🤖 Generated with Claude Code

[flashduty]

Reviewed as part of this week's SDK/component-library review.

The mechanism checks out against the merged code:

• Old entries are exactly newKey + '|' + version — the updated spec pins that (const otherReleaseKey = ${buildRemoteConfigSetup(INIT_CONFIGURATION)!.storeKey}|0.9.0``), so the age-based sweep still finds everything the previous builds wrote.
• The 3-part and 4-part shapes cannot collide: buildKey runs every part through encodeURIComponent, and | is escaped to %7C, so a 4-part old key can never be spelled by a 3-part identity.
• sweepAbandonedEntries(keepKey) still exempts this page's own entry, and a live old-build entry keeps its t fresh, so a long-lived tab on the previous release does not have its entry taken away.
• app_version still rides on the request, so server-side targeting by release remains possible.

One documentation gap in the released changelog, not a code change request:

The v0.3.1 entry covers "entries left by earlier builds are no longer read and are swept after two days", but not the consequence you spell out in the PR body — releases of one site live at the same time now share one entry. For a site on a rolling deploy or a canary where two releases are served at once and the settings are targeted per app_version, the first draw on the new release can be handed the other release's stored rates. That is bounded (the page fetches its own answer and overwrites), but it is the one behaviour an integrator might notice, and it is invisible from the CHANGELOG.

Worth one clause in the v0.3.1 entry ("releases served at the same time share one entry, so settings targeted per application version can apply to the first session of the other release"), so a site running canary rollouts can decide whether it is affected.