docs: record the Spring guarantees of the browserless environment

articles/flow/testing/browserless/multi-user.adoc

@@ -370,6 +370,7 @@ Common gotchas worth keeping in mind:
 - *No parallel access.* Every context is thread-affine. Driving the same [classname]`BrowserlessApplicationContext` from multiple threads in the same test is unsupported.
 - *Security snapshot is per user, not per window.* Two windows of the same user share one snapshot; a security mutation made while one window is active -- including a logout -- is visible to the user's other windows, both already open and opened afterwards. The snapshot is re-captured only on cross-user switches.
 - *Calling Vaadin APIs directly.* DSL methods on [classname]`BrowserlessUIContext` activate the window automatically. If the test reaches for [methodname]`UI.getCurrent()`, [methodname]`VaadinSession.getCurrent()`, or [classname]`SecurityContextHolder` between DSL calls, call [methodname]`window.activate()` first to make sure the thread-locals reflect the intended window.
+- [since:com.vaadin:vaadin@V25.2]#*Spring request and session scopes follow the user.*# A [annotationname]`@SessionScope` or [annotationname]`@RequestScope` bean is resolved against the active user's own request, so two users never share one instance. [annotationname]`@VaadinSessionScope` has always behaved this way, because it resolves against [methodname]`VaadinSession.getCurrent()`.
 - *Anonymous users still go through the handler.* On a secured context, [methodname]`newUser()` with no arguments delegates to the handler, which installs its anonymous-equivalent state (for example, Spring's [classname]`AnonymousAuthenticationToken`).
 
 

articles/flow/testing/browserless/spring-security.adoc

@@ -172,6 +172,24 @@ class SecurityTestConfig {
 ----
 
 
+[role="since:com.vaadin:vaadin@V25.3"]
+== Session Fixation Protection
+
+Spring Security gives the session a new ID when a user authenticates, and an application without Spring Security does the same by calling [methodname]`HttpServletRequest.changeSessionId()` after a successful login. The mocked request performs that rotation instead of refusing it, so a test can drive a login flow that protects against session fixation.
+
+The session itself survives the rotation: the attributes stay, and so does the [classname]`VaadinSession` bound to it. Only the ID changes.
+
+[source,java]
+----
+String idBeforeLogin = VaadinSession.getCurrent().getSession().getId();
+
+// Log in through the application's own flow
+
+Assertions.assertNotEquals(idBeforeLogin,
+        VaadinSession.getCurrent().getSession().getId());
+----
+
+
 .Multiple Users or Windows?
 [TIP]
 This setup drives a single user with a single window. For tests that need several concurrent users or multiple windows of the same user, see <<multi-user#, Multi-User and Multi-Window Testing>>.