refactor(rum): stop acting on a rate that rises to a hundred

[Fiona2016]

Follow-up to #40, before any of it is released.

What goes

Of the three changes that did not wait for the running session to end, the one that acted on a
session sample rate rising to 100 is removed. A session that is not being collected is now left
alone whatever the rate does.

It had the weakest claim to a place:

• setForcedSession() already exists for "collect this visitor now", and is precise where turning a
  global rate to 100 is blunt.
• It was the only one of the three that raises volume, and it did so the same day, for visitors
  nobody had asked about.
• Nothing about "let us see more" is urgent. The other two undo something that cannot be undone
  later — a second of plaintext already uploaded, an event already ingested. This one only delays
  something that can still be had at the next session.

What that buys

Both survivors are about a session that is being collected, so the precondition rises to the top of
the function. The nesting around the privacy comparison goes, the rate check loses its conjunction,
and the guard for a forced session goes back to being simply true — ending a collected forced
session on a rate really would only produce the same session again, which is the reasoning that
guard was written on and that the removed rule had broken. The rule is nineteen lines with no
nesting.

if (!session || !isTypeTracked(session.trackingType)) return
if (privacy level is stricter than the one this session was drawn under) expire, done
if (forcedSession) return
if (sessionSampleRate === 0) expire

The motivation was stated backwards, and is corrected

#40 said this was for visitors who never go idle — a wallboard, a support console, a trading
screen. It is not, and cannot be: settings are fetched at start-up and on session renewal only,
never on a timer, so a single tab that is never reloaded hears nothing about a publish until its
session reaches the four-hour cap. An always-on screen is the case this feature does least for.

What it actually changes is the ordinary visit. A visitor who loads a page downloads the new
settings within seconds — and until now the SDK filed them away and went on under the old decision
for the rest of that visit, up to four hours. That wait is what goes.

The correction is applied to the remoteConfigurationEnabled documentation, to the comment on the
rule itself, and to the changelog, so the next person can tell what this is for.

Testing

format, lint, typecheck, build, check-packages, test:compat:tsc and test:compat:ssr
are clean; the unit suite is green at 2984.

The test that asserted a rate of 100 ends an uncollected session now asserts it is left alone, and
was checked by putting the rule back and confirming it fails. The test for a forced page adopting an
uncollected session goes with the rule that made it necessary.