fix: correct toPercent units and de-duplicate worker.ts/parsing.ts

[lsimpsonsfdc]

Summary

toPercent() reports the wrong usage percentage against the real Anthropic OAuth usage API (GET /api/oauth/usage).

It multiplies utilization by 100, assuming a 0..1 fraction — but the live API returns utilization as a whole percentage already (e.g. 1.0 means 1% used, 31.0 means 31% used). This was confirmed against the same response's own limits[].percent field, which reports the identical value under an unambiguous name. With the * 100 in place, any real, non-zero usage clamps straight to 100% — the dashboard, usage page, and get-usage/get-usage-summary agent tools all report "100% used" for accounts that have barely touched their quota.

This reverses toPercent's previous fix (the LAC-2004 regression tests it added), which was chasing the opposite problem — reported utilization: 1.0 displaying as 1% instead of 100% — under the wrong assumption about the API's units. Both bugs are real; the API's units just aren't what either fix assumed. The new regression test asserts against the values actually observed from a live low-usage account (1% / 31%), not synthetic 0..1 fractions.

While tracking this down, found the actual root cause of why the bug shipped silently: worker.ts carries a full second copy of every helper in parsing.ts — toPercent, parseAnthropicResponse, extractAccountEmail, the whole CLI-output parsing pipeline (stripAnsi, cleanTerminalText, parseClaudeCliUsageText, etc.) — and never imports from parsing.ts (only friendlyErrorMessage was actually wired up). parsing.ts's own comment says these were "extracted from worker.ts so they can be unit-tested," but the extraction never got finished — the copy left behind in worker.ts is the one that actually runs, while parsing.test.ts exercises the untouched copy in parsing.ts. Any future fix to a parsing.ts function (like this one) silently does nothing to production behavior unless the same edit is manually mirrored into worker.ts.

This PR fixes toPercent() and removes the duplication so parsing.ts is the single source of truth worker.ts actually runs.

How to test

npm install
npm run typecheck
npm run build
npm test

Or manually: connect a low-usage Claude account and check the dashboard widget / usage page report percentages that match claude /usage in the CLI, not 100%.

Checklist

• npm run typecheck passes
• npm run build produces dist/manifest.js + dist/worker.js
• Updated the README if a public option or agent tool changed — n/a, no public option or tool changed
• PR is focused (one logical change — the units bug and the duplication that hid it are the same root cause)

[lacymorrow]

Verified the core claim against the live API before reading further. GET /api/oauth/usage on a real Max account just returned five_hour.utilization: 29.0 alongside limits[0].percent: 29, and seven_day.utilization: 5.0 next to percent: 5. So utilization is already a whole percentage and the old *100 was clamping any real usage to 100. Your read is right, and the regression note explaining how this reverses LAC-2004 is appreciated.

The worker.ts dedup is also correct: the removed local copies were drifting from parsing.ts already (the local toPercent had the same *100 bug baked in twice).

Approved the held CI run. Will merge once it goes green.