feat(usage): [usage.repo_aliases] folds two names for one project

[as-koshiyama]

What

The same project legitimately earns two rows in the Projects view: a checkout with an origin remote reports owner/name, while a copy of the same code with no remote — a scratch workspace, an agent's own working folder — reports its directory basename. On a real machine that split HAI Neo from holistic-ai/hai-neo, cutting one project's ~$450 of spend into two rows that ranked separately.

Design

surface never guesses that two names are one project — folding spend together on a string resemblance is misattribution, the thing the Projects view promises never to do silently. The operator declares it instead:

[usage.repo_aliases]
"HAI Neo" = "holistic-ai/hai-neo"

The declaration is applied where prices are — at read time, never to the stored ledger keys — so an alias added today regroups the whole window retroactively, and a wrong one is one edit away from undone. One hop only: an alias pointing at another alias does not chase, so a config cycle cannot loop a scan. Project totals, daily chart rows, --json's by_repo, and the session breakdown all follow the alias (the session pane filters by the name the row above shows, so sessions recorded under either name attach to the folded row).

Verification

Three new tests: two names fold into one project across by_project and project_rows; aliases are never persisted and never chase (the stored keys stay raw); and end-to-end at the App layer — one Projects row carrying both names' tokens with both sessions attached. Docs in configuration.md (new section), dashboard.md's attribution paragraph, and surface.example.toml. cargo fmt, clippy -D warnings, all 246 tests pass.

Independent of every open PR; needs the usual one-line CHANGELOG rebase after whichever lands first.

🤖 Generated with Claude Code

[kleyt0n]

Approved. But make sure that the changes are not generalized and will not provoke any damage to perfomance.

[as-koshiyama]

Superseded by #56, which packs this together with #52 and #51 into one branch for review. 54bbe87 is carried over intact.

@kleyt0n — your review comment here was dismissed before it could be actioned, so it is restated verbatim in #56's body rather than lost with this PR. It is flagged there as still open, not resolved.