fix: eliminate Trae parse blocking that stalled serve/first paint (#40)

[juliantanx]

Closes #40.

Problem

On Windows with a large Trae snapshot store (~72 git repos, ~696 tags), aiusage serve opened to a dashboard stuck on the loading state. The cause was two-fold:

1. Trae parser spawned one git log per tag (plus a second full pass for the no-chain-start fallback) — ~768 git subprocesses per parse. On Windows process spawn is ~40–60ms each, so a single Trae parse took ~40s (REFRESH ms=40815 in the report), blocking /api/refresh.
2. Frontend awaited triggerRefresh() (the full parse) before rendering, so the page never showed existing DB data during that ~40s.

Changes

• parse-trae.ts: replace the per-tag git log scan with a single git for-each-ref --format='%(refname:short)\t%(creatordate:unix)' call per repo. Git subprocesses drop from ~768 to 72 (one per repo). %(creatordate:unix) is semantically equivalent to the previous git log %at for these snapshot tags, so parsed records are unchanged.
• web/routes/+page.svelte & overview/+page.svelte: render whatever is already in the database first, then trigger the refresh in the background and update silently. First paint is no longer blocked on log parsing, regardless of how slow any single source is.
• tests/commands/parse-trae.test.ts (new): builds real git snapshot repos and covers tag parsing, the earliest-tag fallback, the lastImportedAt watermark, and missing ModularData.

Expected impact

• Trae parse on the reporter's machine: ~40s → ~3–4s.
• Home/Overview show cached data immediately; fresh parse lands in the background.

Test plan

• npx vitest run in packages/cli — 402/402 pass (incl. 4 new parse-trae tests)
• parse-trae tests pass both before and after the refactor (behavior preserved)
• svelte-check — no new errors in changed files
• Manual: on a Windows machine with a large Trae snapshot store, confirm serve first paint is instant and refresh completes in seconds