Render CI health as a repos × checks matrix on the Security tab

[exploreriii]

🧑‍💻 Intermediate Issue — a complex task spanning multiple modules, with real design decisions to own.
Time: ~25 hours · Prerequisites: comfortable navigating this repo (a completed beginner issue is the usual route; demonstrated CI/CD proficiency substitutes for workflow-focused issues).
We expect more than "it works": maintainable code that fits the existing architecture.

The task

Blocked by #359 — its ci_health_checks.csv schema is this view's input, and its failures table means nothing waits on this issue.

Problem:

Once ci_health lands, its overview problem is 12 checks × ~41 repos — too many cells for a table, exactly the shape the HIPs coverage matrix already solves. The matrix component is generic by design ("a generic entity × category matrix" per its own type docs), but its cell model is HIP-flavored: {merged, open} counts with a magnitude heat ramp. CI health needs categorical cells: pass / fail / na / review.

What done looks like:

A repos × checks matrix on the Security & scorecards tab: rows = repos sorted worst-first, columns = checks grouped into bands by family (supply chain / required apps / hygiene — mirroring how the HIP matrix bands SDKs), cells rendering the categorical status distinctly (na must never read as fail), and the evidence popover showing each finding's file:line — the same drill-through the HIP matrix does for PR evidence. Server side, a views module builds the matrix doc from the findings CSV following the CUSTOM_VIEWS_MODULE pattern (export/hip_views.py is the worked example). The design decision you own: generalise MatrixView's cell model versus a sibling categorical view — argue it in your approach comment; drive-by breakage of the HIP matrix is the risk either way, and its existing tests must stay green.

Modules involved / constraints: export/ (new views builder), dashboard_spec/security.py (view registration), web/src/api.ts + the matrix components and their tests. Maintainer-side presentation research exists (failures table + KPI tiles ship with #359; this matrix is the browse layer) — non-binding.

How to work on this

1. Claim it: comment /assign and wait to be assigned — unassigned PRs are closed automatically.
2. Get a plan: once assigned, comment @coderabbitai plan for a draft plan, then do your own investigation — docs/architecture.md maps the layers and their rules.
3. Propose your approach as a comment before coding. A paragraph is enough; early feedback here routinely saves days of rework.

🤖 AI: tools are welcome; verified work is required — you can explain every line and defend every design choice. See the AI policy. Fully automated bot PRs are closed.

Worth knowing about this repo before you design:

• The layer rules in docs/architecture.md are strict — review will hold your solution to them.
• Tests mirror src (tests/<pkg>/test_<module>.py), and the output-contract test pins the pipeline output surface — if your change adds or renames outputs, update the contract deliberately.

Before opening your PR:

• I proposed my approach on this issue and incorporated any feedback
• The solution fits the existing architecture and layer rules, and is clear enough for others to debug without me
• Tests cover the happy path, edge cases, and error handling (testing guide)
• I reviewed my own diff line by line; scope is limited to this issue
• Workflow checks pass — CI green, signed commits, linked issue

Stuck? Comment here with what you've tried — see getting help.