BYOK: tighten ai-key writes to repo owners (not org MEMBER / read COLLABORATOR)

[JSONbored]

Part of #525. From the BYOK security audit.

requireSessionRepoAccess grants repo scope when the caller authored a PR with author_association OWNER/MEMBER/COLLABORATOR on an installed repo (src/services/control-panel-roles.ts ~250-252). MEMBER = org membership (not necessarily repo write); COLLABORATOR can include triage/read. For the secret-bearing ai-key POST/DELETE routes specifically, that's broader than ideal — a low-permission collaborator who opened one PR could set/replace/delete the repo's BYOK key.

Fix: for ai-key writes, require write-capable access — e.g. author_association === OWNER, or resolve real GitHub repo push permission via the installation, rather than inferring from PR author_association. Keep MEMBER/COLLABORATOR acceptable for the non-secret ai-review config. Avoid locking out legitimate write-collaborators.

Severity: low (privilege granularity; authenticated + repo-scoped already required).

[JSONbored]

Deferred from the BYOK round-2 PR (#680) — needs real push-permission resolution.

Code analysis during round 2 found that naively narrowing this would regress legitimate access:

• The "owned repo" access axis (buildControlPanelAccessScope in src/services/control-panel-roles.ts) is installation-account-based — ownedInstalledRepos requires installation.accountLogin === session.login. For org repos the installation account is the org, not the individual maintainer, so org maintainers do NOT qualify via the owned axis.
• GitHub's author_association is OWNER only for personal repos; org repos return MEMBER/COLLABORATOR. So restricting ai-key writes to OWNER-association (or owned-axis only) would lock every org-repo maintainer out of managing their own BYOK key, leaving only operators.

Correct fix (own PR): resolve the caller's real repo push permission via the installation token (GitHub GET /repos/{owner}/{repo}/collaborators/{username}/permission, or the installation's repo list) and require write/admin for ai-key POST/DELETE, while keeping MEMBER/COLLABORATOR acceptable for the non-secret ai-review config. This adds a (cached) GitHub API call to the auth path and needs its own tests/mocks — out of scope for the round-2 hardening, tracked here.

Current state is safe: ai-key writes already require an authenticated session with a maintainer/owner/operator role and repo-scoped access (PR author_association OWNER/MEMBER/COLLABORATOR on the installed repo, or repo/account ownership), or a server-to-server token. This issue narrows that for the secret-bearing routes specifically.