feat(dashboard): answer "is my plan worth it?", carefully

[pitimon]

Summary

Closes #106. README:32 already made this claim and the product did not compute it — it showed what usage would cost at list price, and it showed a quota bar, but the comparison was left as mental arithmetic against a plan price nothing ever asked for.

Every input already existed: per-source cost per window and the pricing tier saying how much to trust it, both already on the model-breakdown endpoint.

The arithmetic is a subtraction. The labelling is the hard part — which is why the logic lives in a pure module with its own tests rather than inside JSX.

Three rules, each with a test that fails if a future edit drops it

1. It never says "you saved." This is list-price-equivalent, not a counterfactual bill — anyone actually on the API would use it differently. A test asserts the rendered card contains no saved / savings / wasted / worth it / bargain, and that the disclaimer always renders.

2. It inherits the pricing caveats from #92. If any model in the window is unpriced or fuzzy-matched, the figure is a floor and says so, naming the models. unattributed from #94 counts as unpriced. One floor anywhere makes the whole roll-up a floor — averaging confidence would let a well-priced provider vouch for a badly-priced one.

3. Under-usage reads exactly like over-usage. "$3 of usage on a $20 plan" is a downgrade signal and is as useful as the other direction, so neither gets a colour or a verdict. Tested by asserting the below case renders the same sentence with no over/under language.

Privacy

The plan price is entered by the user and stored in localStorage. Never sent anywhere — no plan catalogue to maintain and go stale, and a plan price is exactly the kind of thing this product promises not to transmit. A test asserts the storage hook contains no fetch and imports no API client.

Absent is never zero

Three places, because zero is the flattering direction every time:

• no stored price → no comparison, rather than a $0 plan (infinitely over by construction)
• clearing the field → stores nothing, not 0
• a provider the user has not priced → left out of the roll-up entirely, rather than inflating the list-price side against a smaller plan side

I nearly shipped this without an input

The card rendered "enter what you pay" with nowhere to enter it, which is not a feature. The inputs render in both states, because in the empty state they are the only way out of it.

README

README:32 rewritten to match what shipped rather than left overselling it — the issue's own instruction if the honest framing could not be made to fit. It can, so the claim now names the window, the list-price-equivalence, and the floor.

Test plan

• ci:local exit 0 — 952 root tests, 302 dashboard
• 14 on the pure comparison: both directions, null/0/negative/NaN plan prices, floor from unpriced, floor from fuzzy, unattributed counted, exact when all tiers are exact, missing models/totals, dedup + sort, roll-up sums, one-floor-poisons-the-roll-up
• 8 on storage: round-trip, clearing removes rather than stores zero, non-positive and non-numeric stored values dropped, corrupt JSON, a stored array, a write that throws (value survives in memory), key case-normalised
• 14 on the card, including the four input tests and read-only when no handler is supplied
• A wiring guard — a source-fact test, not a render test, because there is no DashboardView harness. This session already produced the lesson twice: a Vite build stayed green over a deleted identifier, and a notice went into a component nothing mounts.

Two guardrail false positives, reworded rather than baselined

The ui-hardcode scanner reads render(<X/>) in an arrow body as raw text, and treats the => before a return ( as an opening JSX tag so everything after it becomes text. Both fixed by structure, not by widening the baseline.