feat: read-only private GitHub App connector for design-partner onboarding

[parthrohit22]

Problem

The intended customers are teams with private inherited Python/TypeScript services, but PARTHA today only supports archive upload and public GitHub import. The 2026-07-27 audit (§14 contradiction #2, §15 Risk 5) states the target private/team use "cannot be onboarded" — there is no private connector. Without it, even recruited design partners (P0-C) cannot bring their real private code, which blocks the entire Stage 1 wedge validation.

Proposed Behavior

Add a read-only private GitHub connector (GitHub App, not PAT) that imports an exact revision into the existing sealed ri.v1 pipeline. Installation is least-privilege (contents: read-only), supports revocation, and leaves an audit trail of what was imported and when. No write access, no PAT storage.

Scope

• New connector subsystem under apps/backend/app/github/ (extend the existing GitHubClient which already does public HTTPS import + safe clone — reuse, don't duplicate).
• Credential model: encrypted GitHub App credentials per user (mirror the existing Fernet-encrypted AI provider key pattern).
• Import path reuses RepositoryService.import_github_repository and the existing snapshot pipeline.
• API: connector install/revoke/list + import-by-repo; owner-scoped.
• Documentation: self-hosted runbook update (note: audit CQ-L2 found SELF_HOSTED.md stale re: Compose ports — fix that here too).

Acceptance Criteria

• A user installs a read-only GitHub App and imports a private repo at an exact revision.
• Least-privilege scope verified (contents: read-only; no write, no PAT at rest).
• Revocation removes stored credentials and is reflected in the connector list.
• Every import records an audit entry (repo, revision, timestamp, owner) — no silent imports.
• Reuses the existing safe-clone + ri.v1 sealing path; no second parser.
• Backend tests cover install/revoke/import failure (bad creds, revoked app, missing perms).
• npm run build:frontend + backend pytest pass.

Priority

P1 - High

Risks and Dependencies

• Depends on P0-A (symlink closure) and P0-B (honest core) being merged first — private code widens the trust boundary, so the source-custody defects must be closed before accepting untrusted private repos.
• Depends on P0-C for partner demand validation.
• Security: GitHub App webhook signature verification, idempotency, and branch/PR events are out of scope for this spike (deferred to later per audit §16 "GitLab/Bitbucket/Azure DevOps" later-phase note) — scope is import-only.
• Must not weaken the existing AI egress allowlist/DNS-pinned controls.