v0.333.0: the file manager's own token ends with the dashboard sign-out (R-1155); the recovery-code page says the code becomes live after the check (R-1161)

CHANGELOG.md

@@ -1,3 +1,31 @@
+## v0.333.0 — the file manager's own pass ends with the dashboard sign-out (R-1155); the recovery-code page says the code becomes live after the check (R-1161) (2026-10-19)
+
+**MinAgent: 0.158.1** — the floor's, carried. Neither change needs a new agent (R-1161's two texts are chosen by the
+claim answer the agent already gives). No golden (`09` §3 decision 250). Task: the second day brief of 2026-10-19.
+
+- **FileBrowser's own token no longer outlives the dashboard session (R-1155).** Measured on demo-hp before the fix: the
+  one-sign-in user's FileBrowser token (HS256 JWT; claims `belongsTo`, `Permissions{admin,…}`, `iat`, `exp` 2 h, `iss`
+  — no user name) still opened `/api/users?id=self` (200) after the dashboard sign-out, as a cookie and as a Bearer
+  header. The forwardAuth answer (`ServeFilesAuth`) now refuses a request that has NO valid files cookie but carries a
+  NON-admin FileBrowser token — in the `filebrowser_quantum_jwt` cookie, an `Authorization: Bearer` header or the
+  `auth` query parameter — exactly like a stale files cookie: both cookies cleared, a browser sent to the dashboard
+  (`/__files/open`, which re-issues the pass while the session lives), anything else 401. `admin`'s token (the password
+  fallback) and FileBrowser's sign-in page still pass; an unreadable token passes on to FileBrowser, which refuses it.
+  The signature is not checked here and need not be: this check can only refuse. `carriesNonAdminFileBrowserToken`;
+  `TestFilesSSO_R1155_HouseholdTokenDiesWithTheSignOut` — red-proved both ways: without the check the household's
+  token alone passes after the sign-out (200); with every token refused, admin's own token gets 302.
+- **The recovery-code page tells the truth about when the code is live (R-1161).** Since R-1151 (agent ≥ 0.160.0) the
+  new code becomes live only when the two words come back; the page still said „Ez mostantól az élő helyreállítási
+  kód". It now shows „Ez a kód az ellenőrzés után lesz az élő helyreállítási kód: írd be lent a két kért szót. Addig a
+  korábbi kód marad érvényes, akkor is, ha most bezárod az oldalt. …" (key `backups_escrow.ez_a_kod_az_ellenorzes`,
+  English twin), and the old sentence only when the claim answer says no confirm is required (an agent before 0.160.0,
+  which stores the package at the claim). i18n parity: `escrow_first` and `escrow_receremony` re-captured (the
+  reason: R-1151 made the old sentence untrue); every other fixture byte-identical. `TestEscrowTemplates_Render`
+  pins both texts and the switch — red-proved with the old template.
+- **The Chrome „Install" chip on the file manager: NOT-A-FINDING.** FileBrowser 1.5.6 always links
+  `/public/static/site.webmanifest` (display `standalone`); its only PWA setting is `disablePWAInstall` (set — it hides
+  FileBrowser's own prompt). No setting stops the manifest; FileBrowser is not patched.
+
 ## v0.332.0 — one sign-in for the file manager (R-1100, operator D16 = yes); the new recovery code replaces the old one only after the household typed it back (R-1151) (2026-10-19)
 
 **MinAgent: 0.158.1** — the floor's, carried. Neither change needs a new agent: the file manager's sign-in is the