feat(projects): the panel ignored every filter the client sent

[pitimon]

Summary

Addresses the surfacing half of #102. Not the cost half — see the bottom.

The client has always sent from/to/source/limit/timeZone (dashboard/src/lib/api.ts:90-109). The handler read none of them and aggregated project.queue.jsonl unconditionally.

Concrete failure, as #102 describes it: pick "24h", every other card narrows, Projects keeps showing all-time totals with nothing on screen saying so. Someone comparing "this week's spend by repo" was reading lifetime numbers.

Pure surfacing — hour_start is already on every row, and this uses the same getTimeZoneContext + rowDayKey shape as the other range-filtered handlers, so a day boundary means the same thing on every card.

One difference that matters

The other handlers compare against "" directly, which is safe there because the client always sends both bounds. Here it does not, and day <= "" is false for every day — the panel would have gone blank whenever only one bound was set. An absent bound means no bound, with a test for each direction.

The per-source fallback path ignored the window too, and that is the path a user sees before project attribution has ever synced. Filtered as well.

Sources with no per-repo attribution are now named

projectBucketsQueued exists in 7 parsers. Cursor, Copilot, Zed, Goose and Kiro have no per-repo story at all, and simply omitting them looks identical to "that tool cost nothing here" — the panel under-reported while looking complete.

The list respects the same window as the entries, so a tool is not called unaccounted-for in a window where it contributed nothing.

The notice went into DataDetails, which is what the dashboard actually renders. I edited ProjectUsagePanel first — the ui-hardcode ratchet is what surfaced that the change was going into a component nothing mounts. Reverted.

Structure

The handler block reached 129 lines once it stopped ignoring the query string, so the aggregation is extracted and exported: buildProjectUsageSummary (36) with buildProjectFilters (23), findUnattributedSources (13), aggregateBySource (22), aggregateByProject (19), rankProjectEntries (9). The whole thing is now testable without standing up a server.

Test plan

• ci:local exit 0 — 924 root tests (+10), 258 dashboard (+2)
• A date window narrows the panel; without one, everything still counts
• An absent from or absent to returns results rather than nothing
• source filter; limit truncates after ranking so it keeps the biggest; a nonsense limit (0, -3, abc, empty) is ignored rather than emptying the panel
• Unattributed sources are listed, exclude sources that are attributed, and follow the window
• The fallback path is filtered too, and still refuses to fabricate a project_ref (https://${src}.ai resolves to unrelated domains and was once a clickable href)
• An empty window returns no entries rather than quietly falling back to all-time
• Two component tests: the notice renders with the source names, and is absent when everything is attributed

Not in this PR

Adding model to project rows (project|source|hour → project|source|model|hour) and the per-repo cost that unlocks. That is a data-model change carrying the mixed-era double-counting risk #102 flags — legacy and new rows describe the same bucket at different granularity, and summing both double-counts. It wants its own PR, its own keep-last rule, and a fixture containing both eras.

Two guardrail false positives, reworded rather than baselined

The ui-hardcode scanner reads length > 0 ? ( as a JSX text node, and reads a three-digit issue reference as a hex colour. The second one tripped on the comment explaining the first.