feat(rum): end the session when new settings decide its fate

[Fiona2016]

Stacked on feat/remote-sampling-configuration, and targets that branch. Review only the two
commits on top of it.

Why

Settings published from the console apply to sessions created after they arrive, and to nothing
else. A session ends after fifteen minutes without activity, or four hours outright, so for a
visitor who never goes idle — a support console, a trading screen, a wallboard — the change can be
hours away. Those are exactly the visitors who produce the most data, so a change made to stop a
flood reaches the flood last.

What it does

Three changes no longer wait, and they are exactly the three whose effect on the running session
can be told without drawing again:

Change	Current session	Action
session sample rate → 0	being collected	end it
session sample rate → 100	not being collected	end it
defaultPrivacyLevel gets stricter	either	end it
any other rate	either	leave it
only the custom bag, the trace rate or the replay rate changed	either	leave it

Ending is the whole point, rather than flipping the running session: the old session is collected
to its end as it was begun, so no replay is masked in one half and plain in the other, and no
session is invented that begins in the middle of a visit. The visitor's next action starts a new
session, which draws on the settings that just landed. The recorder already stops on session
expiry and starts again on renewal, so a tightened privacy level stops uploading plaintext at the
moment it arrives.

0 and 100 are the only rates that can decide anything, because they are the only ones whose
outcome needs no lottery. For any rate in between there is no answer to "should THIS session have
been kept" — only a second draw could produce one, and drawing twice turns a rate p into p²
with nothing to show for it. A privacy level that gets looser deliberately waits too: the
delay is what leaves room to undo a mistake, and what it costs meanwhile is more of the data
already being collected. The judgement is on the direction, not the volume.

How it is wired

store() now reports whether the response actually reached storage, and the fetcher emits
REMOTE_CONFIGURATION_STORED only when it did — a stale response and a failed write both stay
silent, since a subscriber must never act on settings the next draw will not find.

The comparison lives in the session manager, which already holds the record of what each session
was drawn under and the ability to end one. Remote configuration needs no reference to the session
manager.

What it compares is what the running session was drawn under against what a draw would use
now. That is not the previously stored settings: settings are stored while a session runs, and the
session was drawn on whatever was stored before that. Ending the session is precisely what makes
that difference disappear, which is why this needs no "only interrupt once per version"
bookkeeping to be idempotent — the same response arriving again, in another tab, on a retry or
after a reload, finds nothing left to act on.

Two things are deliberately left alone:

• A session the host application forced is not ended by a rate. Every draw it makes is
  collected regardless, so ending it would only replace it with an identical forced session. A
  tightening privacy level still ends it — forcing decides whether the visitor is collected, not
  how much of their page may be uploaded in the clear.
• The replay sample rate is not one of the three. It decides a draw nested inside the session
  draw, and a rule for it would first have to say what happens to a replay that was forced on.

Known limitation

Settings are still fetched only at start-up and on session renewal. A visitor who never goes idle
therefore never fetches again, so an immediate change cannot reach the very sessions it was most
likely meant for. Closing that gap needs a signal on a channel those visitors do use.

Notes for integrators

beforeSampling is now also called away from a draw, to resolve which rate newly delivered
settings would actually apply. The documentation now asks for a callback that is free of side
effects and answers the same way for the same input. Both were already implied by it running
inside session creation; neither was written down.

Testing

typecheck, lint and format are clean and the unit suite is green (2947).

Twenty-four new unit tests cover each rule and each non-rule — twenty on the decision itself, four
on the announcement that triggers it. Every one of them was checked by
reverting the implementation and confirming it fails: neutralising the decision fails the eight
tests that expect a session to end, widening it to fire on any change fails the ten that expect a
session to be left alone, and removing either guard fails the test written for it.

[Fiona2016]

CI does not run automatically on this PR: the workflow only triggers for pull requests targeting main or publish, and this one targets a feature branch. Triggered manually on the branch instead — https://github.com/flashcatcloud/browser-sdk/actions/runs/33352709371

[Fiona2016]

Superseded by #40, which replays these commits on publish now that feat/remote-sampling-configuration has landed there, and carries the review fixes on top. Merged there.