fix(security): stop caching tokens.json/users.json in memory

[steve-krisjanovs]

Summary

Found while verifying fix/loopback-auth-bypass (#77): FileTokenStore and FileUserStore cached their JSON file's contents in memory on first read and never invalidated it. Their own doc comments stated the assumption plainly — "the daemon is single-process" — which is false in practice: llmux token create/revoke, user reset-passphrase, etc. all run as separate short-lived CLI processes against the same files while a daemon may already be running.

Confirmed live: a token minted via the CLI while a daemon was already running was not recognized by that daemon until restart, and revoking a token via the CLI did not take effect against an already-running daemon until restart — the exact opposite of what revocation is supposed to guarantee. Mutations through the daemon's own in-process handlers (e.g. the web UI's revoke button) worked fine, since they share the same cache instance; only cross-process mutations were invisible.

Fix

Stop caching. load() now always re-reads and re-parses the file. Both files are a handful of tokens/users — re-parsing on every call is cheap next to the rest of a request, and it's a much smaller, more correct fix than adding cross-process invalidation (file watching, a reload signal) for what a single readFileSync already solves.

Test plan

• npm run typecheck / npm run build clean
• Minted a token via a separate CLI process — immediately usable (200) against the already-running daemon
• Revoked that token via another separate CLI process — the running daemon immediately rejected it (401), no restart
• Normal auth (GET /, GET /account with a valid bearer token) confirmed unaffected

🤖 Generated with Claude Code

https://claude.ai/code/session_01Au8T9RPCb6wbgiEecQrBfZ