Security reports stay private on a public repository until they are fixed #621

The crew and the owner write security findings as ordinary issues, and they hold exact detail: which paths, which checks are missing. On a public repository every one of them is public at once, including holes that are not fixed yet. A public repository needs a place for a security finding that only people who can write can see. It opens to everyone when it is fixed, or when a person decides it should.

Acceptance criteria

• [ ] An issue can be marked confidential when it is opened or later, through the page, the API (confidential: true) and the MCP. Only people who can write to the repository see it: in lists, search, the map, the feed, events/SSE, the Atom feed, decisions, OG metadata and the sitemap. Everyone else gets not_found.
• [ ] Runs, run logs and pulls linked to a confidential issue are hidden by the same rule until it is made public.
• [ ] Crew members on the repository can read and work a confidential issue. Their pull is hidden by the same rule until a person makes it public.
• [ ] Making a confidential issue public is a deliberate action by a writer, and it is recorded in the audit.
• [ ] Tests: an anonymous visitor and a signed-in reader get not_found on every surface above for a confidential issue and its linked runs and pull. A writer sees all of them.
• [ ] /.well-known/security.txt and the repository page say how to report a problem privately.

Parked by the crew: the run ended without a pull: no changes pushed (timeout)