Document what each browser actually does with cross-domain auth (#2222)

Measured on real domains over real certificates, Remark42 on one registrable
domain and the host page on another, with a control cookie behind every
blocked column so a run that blocks nothing cannot report a pass.

Three results the manual did not carry. Safari blocks third-party cookies out
of the box, so AUTH_SAME_SITE=none on its own has already stopped working
there, which makes the old recipe broken today and not deprecated later.
Firefox reaches a working session by a weaker route than Chrome and Safari do:
it accepts the server's attribute-less cookie, and because that cookie is
HttpOnly the browser then forbids the widget's script from replacing it, so the
session rides on an ordinary unpartitioned third-party cookie even with the
header flag on. And Firefox's block-all setting discards partitioned cookies
too, so no configuration survives it.

Two parameter descriptions were wrong in ways that matter here. AUTH_SAME_SITE
default emits no SameSite attribute rather than Lax, which is precisely what
lets the widget's own cookie land on Chrome and Safari. And AUTH_TTL_COOKIE
does not govern the cookie that carries the session under the header flag,
since the frontend hardcodes 200h to mirror the default.

site/content/docs/manuals/separate-domain/index.md

@@ -46,11 +46,9 @@ Note that this applies to Email, Telegram and anonymous authorisation, which the
 ### What each browser actually does
 
 Measured on real domains over real certificates, with Remark42 on one registrable domain and the
-host page on another, signing in and then reloading. Chrome and Firefox were driven through
-Playwright, Safari 27 through its own WebDriver, so the Safari column is Safari itself and not an
-approximation of it. Every "blocked" column below was verified with a control cookie: an ordinary
-third-party cookie written from inside the widget frame has to be dropped, or the run is not
-blocking anything and proves nothing.
+host page on another, signing in and then reloading. Every "blocked" column below was verified with
+a control cookie: an ordinary third-party cookie written from inside the widget frame has to be
+dropped, or the run is not blocking anything and proves nothing.
 
 | configuration | Chrome, default | Chrome, third-party cookies blocked | Firefox, default | Firefox, "block all third-party" | Safari |
 | --- | --- | --- | --- | --- | --- |
@@ -61,9 +59,8 @@ blocking anything and proves nothing.
 Three things in that table are worth spelling out.
 
 **Safari needs no configuring to break the old recipe.** It blocks third-party cookies out of the
-box while still honouring `Partitioned`, so `AUTH_SAME_SITE=none` on its own has already stopped
-working there for every reader. This is not a future deprecation to plan for. With the header flag
-the widget's own partitioned cookie is readable in the frame and the session survives the reload.
+box, so `AUTH_SAME_SITE=none` on its own has already stopped working there for every reader. This
+is not a future deprecation to plan for.
 
 **Firefox reaches "works" by a different route, and a weaker one.** Chrome and Safari refuse the
 server's cookie when it carries no `SameSite` attribute, which leaves the field clear for the