feat: durable private-repo re-clone (authenticated clone + token-expiry handling)

[DevanshuNEU]

Problem

Private-repo support has two gaps, and #311 deliberately leaves both out of scope:

1. Authenticated cloning is not wired today. All clone_from calls pass a bare git_url with no credentials (repo_manager.py, anonymous_indexer.py). repos.py:364-369 explicitly blocks private repos. The GitHub OAuth token (github.py) is captured and used for GitHub API reads, not for git clone. So private repos cannot be indexed at all right now.

2. Durable re-clone for private repos (the [OCI] Durable repo-state v0.1: survive Railway redeploy (lazy re-clone) + recover stuck indexing jobs #311 follow-on): once authenticated cloning exists, the lazy re-clone chokepoint (ensure_clone) must replay credentials after a Railway redeploy. That couples a repo's availability to a live token, which introduces a UX cliff: a redeploy the user never saw can surface as 'reconnect GitHub' if the token expired/rotated between index time and re-clone time.

Scope (when picked up)

• Decide credential model: GitHub App installation token (refreshable) vs stored user OAuth token. Prefer installation token to avoid silent expiry.
• ensure_clone injects credentials for private repos on re-clone; never persists a raw token in the stored git_url.
• Token-expiry handling: detect expired/revoked creds and return an actionable 'reconnect GitHub' response (the RepoCloneError 503 from [OCI] Durable repo-state v0.1: survive Railway redeploy (lazy re-clone) + recover stuck indexing jobs #311 is the seam).

UX requirement

A redeploy must never silently break a private repo with a cryptic error. Worst case is a clear, actionable 'reconnect GitHub' prompt.

Blocked by

Authenticated cloning existing at all (gap #1 above).

Related

• [OCI] Durable repo-state v0.1: survive Railway redeploy (lazy re-clone) + recover stuck indexing jobs #311 (durable repo-state v0.1; public-only; established the ensure_clone chokepoint + RepoCloneError 503 seam)
• ADR: DevVault oci/decisions/2026-06-08-durable-repo-state-v0.1.md (Failure modes after shipping)