InMemoryReactiveSessionRegistry can lose a session under concurrent save/remove

Describe the bug

InMemoryReactiveSessionRegistry can lose a session when saveSessionInformation and removeSessionInformation run concurrently for the same principal.

The per-principal session set is updated non-atomically:

• saveSessionInformation calls .add(...) outside the computeIfAbsent mapping function.
• removeSessionInformation prunes the principal key with a non-atomic get → isEmpty() → remove(principal).

To Reproduce

Principal P owns one session S1:

1. Thread A removes S1 — the set becomes empty, and A is about to remove key P.
2. Thread B saves S2 — computeIfAbsent(P) still sees key P, returns the same set, and adds S2.
3. Thread A removes key P — the set {S2} is orphaned; getAllSessions(P) returns empty and S2 is lost.

A latch-synchronized concurrent save/remove stress test reproduces this.

Expected behavior

A session added concurrently is not lost. The blocking SessionRegistryImpl already performs these updates atomically via compute/computeIfPresent; the reactive registry should do the same.

I will submit a PR with a regression test.

Locate InMemoryReactiveSessionRegistry and compare its saveSessionInformation and removeSessionInformation updates with SessionRegistryImpl, especially the compute and computeIfPresent usage mentioned in the issue. Add the regression test described in the issue, then run the relevant Spring Security session registry tests and confirm a concurrently added session remains discoverable.