Deep check covers only the first private key per section — multi-key sections leave the second key unverified #1

Found during a full-vault audit of ~/Sync/Keys (15 sections, all green) on 2026-10-16.

What happens

key-summary (app/core/keymeta.rkt) picks the first entry matching known-private-names / private-name-rx and derives + pairs only that one key. check-store shows one row per section, so sections holding two keys report a single fingerprint:

• [payback] holds UPDATE_ED25519_PRIVATE_KEY_B64 + LICENSE_PRIVATE_KEY (with LICENSE_PUBLIC_KEY_FPR) — the overview row shows the update key; the license keypair is never parsed or pair-checked.
• [gptp-studio] holds LICENSE_PRIVATE_KEY (RSA) + UPDATER_PRIVATE_KEY — only the license key is checked; the updater keypair is unverified.

Impact

A corrupted or mismatched second key in a multi-key section shows green in the ⌘R overview. The audit that Keyward exists to replace (hand-run openssl pairing) silently doesn't happen for that key.

Suggested direction

Iterate every private-key entry per section instead of only the first: one summary per key (keyed by entry name), either as multiple rows per section in check-store or a per-entry analyze RPC the sidebar can call. Public-material matching already works per-entry (PUBLIC/_FPR names), so pairing scope just needs to follow its own key.

Resolution (2026-10-23)

Merged in PR #4, commit 1de32f9fa0ceaa7b5855d99e2701262e01da0c73. Every private entry is checked, public anchors are scoped to its purpose, and every declared anchor must match. The existing section row reports failure if any key fails and labels multiple fingerprints. Four failing regressions reproduced before the fix; 69 engine tests and backend compilation pass locally; engine, macOS, Windows and Linux PR checks all succeeded. Test-generated temporary keys only; no real vault was opened during this fix. Purpose-hint UI in #2 and broader delivery gates in #3 remain separate.