Show exact repository coverage for workflow status

[jskoiz]

Verified against main at 715c52e.

Impact

Full dashboard aggregation requests workflow runs only for the first scanLimit repositories (24 by default), while the dashboard can contain many more repositories. The rail says “No failing runs in scanned repos” and “green or unavailable,” but never states whether that means 24 of 87 repositories or all 12 of 12.

The current wording is cautious, but users still cannot quantify coverage or know how much CI state sits outside the bounded scan. This is a completeness disclosure issue, not evidence that a failure currently exists outside the slice.

Concrete code references

• The server slices repositories to the configured scan limit.
• The payload already returns both all fetched repositories and scanLimit.
• Workflow calls and warnings operate only on the sliced repository list.
• The page passes runs and update state to the rail but no coverage counts.
• The rail reports scanned-repository status without the numerator or denominator.

Acceptance criteria

• Once a full payload is available, the workflow rail states the exact upstream coverage, for example “24 of 87 repositories scanned” or “All 12 repositories scanned.”
• Coverage comes from explicit source data (scanLimit plus the full repository count, or a dedicated canonical field), not from the number of returned runs, because zero runs is ambiguous.
• Quick/progressive payloads present coverage as loading or not yet known; they must not imply the quick repository page is the complete account.
• Zero returned runs remains “green or unavailable,” not a claim that every scanned repository passed.
• Existing per-repository failure warnings remain visible alongside the coverage disclosure.
• If the shared payload gains coverage metadata, update the canonical type, producers, consumers, fixtures, and architecture documentation together without aliases.

Test expectations

• Add rail tests for partial coverage (24 of 87), complete coverage (12 of 12), quick/loading state, and partial upstream failures.
• Add a page-level test proving repository filters or hidden-repository presentation do not silently change the upstream coverage denominator.
• Run both Vitest projects and npm run check.

Dependencies / order

Implement after #7, because that issue may change the public scan budget/default and this disclosure should describe the final bounded behavior.

Non-goals

• Increasing scanLimit or fetching workflow history for every repository.
• Claiming that repositories outside the scan are failing.
• Treating no returned workflow run as proof of a green check.
• Adding background polling.