Seed client auth from token file and pin the data dir

AGENTS.md

@@ -41,6 +41,20 @@ direction.
   - **Later policy:** human emulation — snappy first action (~30–80 ms), bulk actions randomized,
     opt-in risky fast mode, free-account limits by default, ability toggles.
 
+## Auth persistence
+
+- Durable credential: the token file, `VESKSLOP_TOKEN_FILE` (default `<DATA_DIR>/token`, mode 600,
+  gitignored). It is the **puppet account's** token; zzib is only the DM test target.
+- `DATA_DIR` is pinned: `$VENCORD_USER_DATA_DIR`, else `$VESKSLOP_DATA_DIR`, else
+  `<appData>/veskslop` (`src/main/constants.ts`). It does not depend on the app/product name, so
+  renames and version bumps do not move the Electron profile where Discord stores the session.
+- On startup the preload asks main for the token (sync IPC) and seeds `localStorage.token` before
+  the client boots, but only when no session exists. `VESKSLOP_FORCE_TOKEN=1` overrides.
+- Recovery: if Discord invalidates the session, run `pnpm poc:qr` for a fresh token and update the
+  token file.
+- Discord deletes the stored token when it thinks devtools opened; keep Vesktop's devtools detector
+  patch (`src/renderer/patches/devtoolsFixes.ts`) so this cannot cause random logouts.
+
 ## How to proceed
 
 **Current milestone — puppeting bridge (testable without Electron).**
@@ -88,7 +102,6 @@ MCP clients (agents) ──Streamable HTTP──▶ veskSlop control daemon
 ## Open questions
 
 - Headless Electron strategy: Xvfb vs offscreen rendering, and what to strip to lighten the client.
-- Token injection path for the official client (localStorage seeding vs client QR UI).
 - Voice/video: what the client's native stack can be driven to do without UI interaction.
 - Scope and auth model of the future remote proxy client and web debug UI.
 - How much of the Vesktop Electron tree gets deleted once the daemon is self-sufficient.