P1: Decide public visibility of the vole repository and scan its history

Why

The release page is only readable by anonymous visitors if the vole repository is readable, and today it is private (default: none). Making it readable also exposes the entire issue and change-request history in the vole branch: the P0/P1 security discussions, incident notes, and every comment. That is probably what an open-source forge wants, but it should be a decision rather than a side effect of making download links work.

Scope

• Decide whether the product repository’s tracker is public, or whether releases live in a separate public repository while the development tracker stays private.
• Before changing the ACL, scan every history that becomes readable: main, the vole branch, and any tags once they exist. Look for private keys, tokens, enrollment links, credentials, customer data, and anything else that should not be public. A quick grep found no keys or invite tokens in vole, but that is not a secret scan.
• Run a real secret scan over both histories (gitleaks, trufflehog, or equivalent) and record the tool and the result here. If it finds something, decide whether to rewrite or accept; rewriting the vole branch renumbers #N and changes the commit ids the audit log refers to.
• Once decided, set read access deliberately (vole admin acl set-default-role vole read) and verify anonymous clone, a release download, and that a private repository still returns 404.
• Record the decision in docs/operations.md or the instance runbook.

Acceptance

• The decision is written down: which repositories are public, and why.
• A documented secret scan covered main and vole before the ACL changed.
• Anonymous read of the release page works, and a private repository still returns 404.
• The public/private boundary is recorded for the first deployment.

Related: #14, #94, #104, #206.