fix(terminal): derive stable write token so operate links survive worker restart

[47seek]

Problem

The web-terminal 「🔑 操作链接」/write link (http://<host>:<port>/s/<sessionId>?token=...) starts returning 403 Forbidden after a while, even though the session is still alive and its read-only 「🖥️ 打开 Web 终端」link opens fine.

Root cause

The read-only view token was already migrated to a stable per-session HMAC (deriveTerminalViewToken), so read links survive restarts. But the write/operate token is still a per-process value minted at worker boot:

const writeToken = randomBytes(16).toString('hex');

A silent daemon restart re-forks every worker, regenerating that token — so every previously-issued write link immediately 403s.

Reproduced on a live session:

• old ?token=… → HTTP 403
• freshly-derived stable viewToken on the same session → HTTP 200

i.e. the session is reachable; only the operate token went stale after the worker restart.

Fix

Derive the write token the same way as the view token — from the host-only dashboard secret — but with a distinct domain separator botmux-terminal-write-v1 so the two capabilities can never collide (knowing the read token must never yield the write token, and vice-versa). A restarted worker re-mints the same operate token, keeping already-issued write links valid.

• Falls back to the random boot token when the secret is unavailable (standalone/test).
• The host-only secret stays masked from sandboxed CLIs, so a sandboxed CLI still cannot mint its own write link.

Tests

test/terminal-write-auth.test.ts adds: write token is stable per session, domain/secret-bound, and distinct from the view token for the same session+secret.

• npx tsc --noEmit ✅
• vitest run terminal-write-auth (31) + worker read-auth integration (1) all green ✅

[deepcoldy]

Follow-up: integration assertion for the stable write token (relay)

Per maintainer request, added the non-blocking test hardening discussed in review: the existing worker integration test already spawns a real worker with a deterministic host-only secret and asserts ready.viewToken === deriveTerminalViewToken(secret, sessionId). I added the parallel assertion for the operate/write capability:

expect(ready.token).toBe(deriveTerminalWriteToken(secret, sessionId));

This locks the real init → refreshTerminalWriteToken → ready.token path end-to-end (not just the pure HMAC helper), so any regression back to a per-process random write token — which is exactly what 403s every already-issued 操作链接 on a worker restart — is caught by CI.

Scope: single test file, +5/-1. No production code touched.

Verification (local, TZ=Asia/Shanghai):

• npx vitest run test/worker-terminal-read-auth.integration.test.ts test/terminal-write-auth.test.ts → 32/32 passed
• npx tsc --noEmit → clean

Commit: 2387ec5