Completed the full "do it all" ask: (1) extended the session-cookie login flow to every remaining browser-facing tool page with a hardcoded token, and (2) built a real, separate password system so browser login no longer requires the raw platform token at all. Closes T-TOKEN-EXPOSURE-AUDIT (435), which had flagged exactly this gap. PART 1 -- extended login flow to 13 pages: db-admin.html, inventory.html, status.html, cai-registry.js, cmd-palette.js, dashboard-control.html, kill-switch.html, ml-popup.js, schedule.html, traffic.html, plus dashboard.html/panel.html/ml-editor.html (which also needed the corruption fix, see below). For each: removed the hardcoded token literal, added the same isAuthError()/redirectToLogin() pattern fix-log.html already used, and an upfront auth-probe call so a missing/invalid session bounces to login.php immediately rather than failing silently mid-page. Two files (dashboard-control.html, schedule.html) had a SECOND fallback token literal beyond the main declaration -- found via a second verification pass, fixed both. backend/jobs/inventory-scan.php (used by inventory.html) also had the old retired token hardcoded server-side -- migrated to auth-lib.php's cai_check_token(), now supports session auth like everything else too. CRITICAL SELF-CAUGHT BUG, found mid-task: while working on dashboard.html for this same rollout, discovered 5 files (cmd-popup.js, commands.html, ml-editor.html, dashboard.html, panel.html) had a corrupted double-prefixed token (yttcom-admin-yttcom-admin-...) from a sed mistake earlier this session -- matched only the hex portion of the old token but substituted the new token's FULL string including its own prefix. This is very likely the actual root cause of USR369's "pages don't load / systems dumbed down / asking for a token" report, not the new login screen (which was a real but secondary finding). Fixed all 5, verified with an EXACT match this time (my earlier substring-based verification had been giving false-positive passes). Logged separately as D795, referenced here since it directly affected this same set of files. PART 2 -- real password system, replacing token-only browser login: built backend/config/password.json (bcrypt hash via PHP password_hash(), never plaintext) and rewrote login.php to check the password first via password_verify(), falling back to the existing platform token if the password fails (so token-holders are never locked out, and forgetting the password doesn't strand anyone). Generated a secure initial password, gave it directly to USR369 in chat (not stored anywhere in plaintext -- only the hash lives on the platform). Used a one-time hash-generator script (backend/tmp/hash-once.php), deployed, called once, then immediately neutered to a disabled stub (no hard delete, per platform convention). Every step backed up before editing (BACKUP.php), syntax-verified (brace/paren balance) before deploy, and functionally tested after: password login confirmed to set a valid session (verified the session cookie alone, with zero token anywhere, successfully authenticated against records-api.php); wrong password confirmed rejected; platform token confirmed still works as fallback login credential.