The sentinel files no forge issue for another repository's red main; that repository's owner is told instead, in words that name the fix #3992

Why: #3948 was filed in trevato/forge for red:<repoId> of trevato/arm, whose main was red because its forge.json lacks check.run. The crew cannot see trevato/arm, so the issue was parked twice. A user's misconfigured manifest is not the forge being unwell.

Done looks like:

• [ ] src/crew/sentinel.ts files a degraded:red:<repoId> finding as an issue only when repoId is the repository the sentinel files into (the forge's own). For any other repository it files nothing.
• [ ] When the red main's check failed before any test ran because the manifest is invalid (src/apps/manifest.ts invalid(...), e.g. forge.json: check.run is required), the vitals card from redSentence (src/checks/red_main.ts) says that the repository's forge.json is invalid, quotes the error, and links to the repository's forge.json rather than reading as a failing test.
• [ ] That repository's owner still sees it: the red card or a notification (src/crew/notify.ts) reaches the owner of the red repository, not only the forge's owner.
• [ ] src/crew/red_fix.ts still finds the fix issue for the forge's own red main (unchanged behaviour, covered by its existing tests).
• [ ] Tests: a red main in a second repository opens no sentinel issue in the forge repo; a red main whose summary is a manifest error gets the forge.json sentence; the forge's own red main still opens one fix issue.

Files: src/crew/sentinel.ts, src/checks/red_main.ts, src/kernel/vitals.ts, possibly src/crew/notify.ts, and their tests. Risk: vitals cards are also read by src/snapshot/verdict.ts and degraded history. Keep the red:<repoId> key stable so history does not fork.