usage-limits: a cache written before #138 may still hold another account's email

[pitimon]

What

#132 / #138 stop TokenTracker from reading another account's Antigravity process. They do nothing about what earlier versions already wrote to disk.

writeAntigravityLimitsCache (src/lib/usage-limits.js:1470-1483) persists account_email and account_plan into ~/.tokentracker/tracker/usage-limits-cache.json. Before #138, on a multi-user host, those fields could belong to whichever account's Antigravity language server the machine-wide ps -ax matched first.

The file is not self-healing in the way that matters: fetchAntigravityLimits returns the cache on its not-configured branch (:1798), so after the fix — when the other user's process is correctly no longer matched — the stale entry is exactly what gets served, and it is served because detection now returns nothing.

Impact

Bounded, and only on shared hosts. A single-user machine can only ever have cached its own data. But on an affected host the address persists indefinitely: nothing expires the Antigravity block on identity grounds, and nothing tells the user it is there.

Established / not established

• Established: the write path stores account_email (:1474), and the read path serves it when live detection returns not-configured (:1798).
• Not established: whether any deployment actually hit this. It needs a multi-user host with a second account running Antigravity; nobody has reported one. This is remediation of a possible artifact, not a confirmed incident.

Suggested work

1. Decide the policy. Options, roughly in increasing cost:
   • Document it — a line in the release notes for whichever version ships fix(usage-limits): scope the Antigravity process scan to the current user #138, saying to delete the file. Cheapest, and does nothing for anyone who does not read it.
   • Invalidate on version — stamp the cache with the writing version and drop an Antigravity block written by a version older than the fix. Self-healing, no user action, but adds a schema field.
   • Invalidate on identity — record the euid/username that wrote it and drop the block when it does not match. Narrower, and closer to the actual invariant, but stores one more identifier in a file that exists to hold quota numbers.
2. Whichever is chosen, the not-configured read branch (:1798) is the place that matters — that is what serves it.
3. A doctor check is deliberately not proposed here: it would have to read the cached email to decide whether to complain about it, and printing another person's address to warn about having stored it makes the problem worse.

Manual remedy in the meantime

Delete ~/.tokentracker/tracker/usage-limits-cache.json. It is a cache; it repopulates from the local user's own providers on the next fetch.

Context

Split out of #132 on review, rather than folded into #138: that PR closes the leak going forward, and the artifact it may leave behind is a separate decision with its own trade-offs.