fix(git-sync): fork-to-own and repo binding use the saved personal GitHub token (#3164)

[dolho]

Summary

Fork-to-own and the post-creation repo binding always asked for a GitHub token in the form, even when the user had a personal token saved in Settings. The create path already resolved that token (resolve_github_pat, tier per_user), but it only used it to read the template.

• Optional token. ForkToOwnRequest.github_pat and BindAgentRepoRequest.github_pat are now optional. A supplied token still wins and is still charset-validated; a blank token is still rejected.
• Fallback to the saved personal token:
  • Fork-to-own uses the resolver's per_user token (crud._apply_fork_to_own).
  • Binding reads the caller's own saved token by user id (db.get_user_github_pat). It never uses the agent's current per-agent token, which is the agent's identity, not the binding person's.
  • Either way the token is persisted as the agent's per-agent PAT with tier fork, exactly as before.
• The platform token is never a fork or bind identity. With no personal token, the request gets a named 400, FORK_PAT_REQUIRED, which points at Settings. Otherwise the destination would belong to the platform account, and the per-agent row would hold the global PAT (ent#162 Decision 2).
• Saved-token failures are named. If the saved token is refused (invalid, can't create the repo, can't push), the response carries token_source: "saved" and the message says to update it in Settings.
• UI. The new SavedGithubTokenField.vue is used in the create form and the bind panel. It reads presence only from the existing GET /api/users/me/github-pat (no new endpoint, never the value). With a saved token it shows "Using your saved GitHub token" and an explicit "Use a different token" override, and the request carries no token. Without one, the field is required as before.
• MCP: unchanged (fork stays UI-only, ent#15).

Changes

• models.py, services/agent_service/{crud,fork_to_own}.py, routers/git.py: the optional token, the fallback, FORK_PAT_REQUIRED and the saved-token wording
• stores/auth.js (fetchGithubPatStatus), SavedGithubTokenField.vue (new), CreateAgentModal.vue, BindRepoPanel.vue
• raw-color-baseline.json: two entries lowered by hand (BindRepoPanel 46 → 41, CreateAgentModal 135 → 126) with a _3164_note. Not regenerated, because that would drop the refrozen block.
• Docs: feature-flows/github-import-intents.md, requirements/github.md

Test Plan

• tests/unit/test_3164_fork_uses_saved_pat.py: 14 pass. It covers the AC cases (a) saved token + no form token forks with the saved one, (b) global-only gives 400 FORK_PAT_REQUIRED and nothing reaches GitHub, (c) a form token beats a saved one, and (d) the same three for binding. It also covers the saved-token error wording and the models.
• 31 related backend files (fork, bind, create): 879 passed, also under -p randomly --randomly-seed=12345.
• savedGithubToken.mount.spec.js: 7 mounted tests. The 5 payload tests fail without the wiring.
• Full npm run test:unit: all passed, including the ratchets.
• Against a running stack built from this branch (an isolated verify-local stack, fake tokens seeded directly):
  • saved token + no form token: 400 FORK_PAT_INVALID, token_source: saved, saved-token wording, and the token is not in the response;
  • platform token only: 400 FORK_PAT_REQUIRED;
  • the presence route returns configured only;
  • no agents were created.
  • A genuinely token-less run wasn't exercised, because the stack's env still supplied a platform token.
• Manual, needs a real token (creates a repo): save a personal token, fork a template without typing one, and check the repo is created under your account and the agent pushes.

Fixes #3164

🤖 Generated with Claude Code

[vybe]

merge-train (2026-10-05, evening run): not on this train. It rides the next one once fixed. CI is green at 512381fc; these were found by tracing the saved-token path, which no test drives through an error or an empty override.

Blocking

1. The unexpected-error handler crashes on the saved-token path. src/backend/routers/git.py:1101 still calls body.github_pat.get_secret_value(), and body.github_pat is None when the saved token is used. Any unexpected bind error then raises AttributeError before the scrub runs, so the BIND_UNEXPECTED_ERROR audit row and idempotency_service.fail(idem) are both skipped and the key stays in flight. Pass user_pat, and add a saved-token case for that branch.
2. "Use a different token" with an empty field sends the saved token. overriding lives only inside SavedGithubTokenField.vue (:63-64); BindRepoPanel.vue:311 and CreateAgentModal.vue:549 guard on !token && !hasSavedGithubPat alone. Choosing the override and submitting it empty binds the saved token. The retry case is the sharp one: type a narrow token, the first submit fails, the panel clears pat by design, the field still shows override mode, and the resubmit persists the broad saved token as the agent's credential. No spec covers override-and-empty. How the parent learns about the override is your call, which is why this was not fixed on the branch.

Needs a decision before it lands

• Admin binding another user's agent. OwnedAgentByName admits an admin, and git.py:994 reads db.get_user_github_pat(current_user.id), so the admin's personal token becomes that agent's PAT by default. Before this PR that needed a typed token. Either restrict the fallback to caller-is-owner or document the behaviour.
• Fork-to-own from an agent key. POST /api/agents is require_role("creator"), which agent keys satisfy as their owner, so an agent can now have a repo created in the owner's GitHub account with the saved token (crud.py:905). Bind is human-only for this reason. If fork should be too, the saved branch needs a not current_user.agent_name check.

Smaller

• SavedGithubTokenField.vue:36-47 hand-rolls its password input; the design-system contract asks for BaseInput.
• Stale docs: architecture/agent-lifecycle.md:191, feature-flows/agent-repo-binding.md:68, feature-flows/template-processing.md:890 still describe the token as always present or model-validated.
• The presence check is "column not null" while the read returns None when the value cannot be decrypted, so the UI can say "using saved" and then get FORK_PAT_REQUIRED.

What held up: precedence (form, then saved, never platform), the field names on both sides, the raw-colour baseline (both files shrank), and the frontend never receives the token value.

[AndriiPasternak31]

Independent /review + /validate-pr pass at 512381f. Same head as vybe's merge-train comment, so his four items are still open. I confirmed each one and have two additions.

Confirmed, with evidence

• git.py:1101 crash (vybe #1). Reproduced with your own bind fixture: bind.saved = SAVED, then _bind raises RuntimeError("header value b'Bearer ghp_saved_personal' is illegal"). The result is AttributeError: 'NoneType' object has no attribute 'get_secret_value' at git.py:1101. The form-token control passes.
  Addition: the audit row and the idempotency release are both skipped, and there's a second problem. main.py has no catch-all exception handler, so the AttributeError's chained traceback ("During handling of the above exception…") logs the original exception text unscrubbed. That's the Bearer <PAT> echo the comment above line 1101 says this branch exists to keep out of the Vector log.
  Fix: scrub_secret_and_urls(str(e), user_pat), plus a saved-token test for that branch. The assert I used:
  assert e.value.status_code == 500 and SAVED not in str(e.value.detail)
• Override + empty field sends the saved token (vybe #2). BindRepoPanel.vue:311 and CreateAgentModal.vue:549 can't see overriding (SavedGithubTokenField.vue:63). Emitting the override state and guarding on !token && (!hasSaved || overriding) closes it. One mount spec per form for override+empty, please.
• Admin bind (D1) and agent-key fork (D2). Both reachable as described: OwnedAgentByName admits admin (dependencies.py:1755), and POST /api/agents is require_role("creator") with no agent_name check on fork_to_own. For D1, note that resolve_github_pat's own docstring says resolution "keys on ownership only, never on a calling/sharing user" (settings_service.py:1019). Keying the bind fallback on owner == caller would match that.

New

• docs/memory/architecture/agent-lifecycle.md:191 still says the user PAT is header-validated at the model for both request types. The saved token is a plain str from db.get_user_github_pat and never passes _validate_pat_secret. It's validated at save time instead (strip + GitHub round-trip, users.py:225), and the doc should say that. The ent#109 bind section there also doesn't mention the fallback yet.
• SAVED_TOKEN_TIERS includes per_agent, but both create-path resolver calls pass only owner_id (crud.py:706,724), so that tier can't occur there. Either drop it or add a comment saying why it's safe if a future caller passes agent_name.

What holds up: reverting the crud and router hunks turns 7 of the 14 new tests red. Adding "global" to SAVED_TOKEN_TIERS turns the global-tier test red. 380 related fork/bind/PAT unit tests pass locally.

The two CANCELLED checks are benign. The first frontend-e2e run was superseded under cancel-in-progress when the ui label and the PR open fired two seconds apart. The superseding run on the same SHA is green, and report only runs on schedule.

[dolho]

Addressed vybe's 10-05 train notes and @AndriiPasternak31's review in a8bc07f6f, and merged dev.

Blocking

1. Crash at git.py:1101: the scrub now uses user_pat, the token actually sent. New test: on the saved-token path, an unexpected error whose message contains Bearer <saved> returns a 500 that doesn't include the token. It still writes the BIND_UNEXPECTED_ERROR audit row and releases the idempotency key.
2. Override with an empty field: SavedGithubTokenField now emits update:overriding. BindRepoPanel and CreateAgentModal check !token && (!hasSaved || overriding). I added one mount spec per form for override-plus-empty: nothing is sent.

Decisions (I took the narrower option in both cases — say if you want the other one)

• D1, admin binding another user's agent: the saved-token fallback now applies only when the caller owns the agent (owner_id == current_user.id). That matches resolve_github_pat's "ownership only" contract. Otherwise the bind returns a named 400 asking for a typed token. Test included.
• D2, fork from an agent key: the saved branch refuses a caller with agent_name set and returns a named 400. An agent can still fork with a token it passes itself. Tests included.

Smaller

• SAVED_TOKEN_TIERS is now {"per_user"}, with a comment explaining why per_agent is excluded. per_agent is also added to the "never the fork identity" parametrize.
• The field uses BaseInput.
• GET /api/users/me/github-pat now also returns usable (present and decryptable), and the forms read it. A saved token that can't be decrypted no longer shows "using saved".
• Docs: agent-lifecycle.md now says the saved token is validated at save time, not by the model. agent-repo-binding.md and template-processing.md describe the optional token.

The touched test files were run locally (19 backend + 37 frontend). The full suite runs in CI.

🤖 Generated with Claude Code

[vybe]

merge-train (2026-10-07): validated at 88d44bf85. Every item from the 10-05 train note and the review is fixed, and each test goes red with its fix reverted. Riding this train. Non-blocking follow-ups:

1. The fork guard (crud.py:910) and the bind guard check agent_name, which is a denylist, so a scope="system" key resolves to the admin and can fork with the admin's saved token. That's consistent with ADMIN_GATE_SCOPES today, but is_person_principal would make it human-only (bug(auth): agent-scoped keys can toggle their own agent's autonomy — PUT /api/agents/{name}/autonomy lacks reject_agent_principal #2996 pattern).
2. In BindRepoPanel.vue:245-250, closeForm clears the token but not the override flag. It fails safe, but after a reopen the panel reads "using saved" and refuses to submit.
3. Nothing tests the new usable field in users.py:208.

[vybe]

merge-train (2026-10-07): pushed 3c8a347b0 to this branch — mechanical. regression diff failed here and on the train with one new failure: test_ent162_per_user_github_pat::TestReadEndpointNoEcho::test_status_endpoint_returns_flags_only. Its exact-dict assertion predates the new usable field, so it now expects {"configured": True, "usable": True, "has_global": True}. The no-echo checks are unchanged, and this also gives usable its first test (follow-up 3 above).

merge-train 2026-10-07: every requested change was addressed in a8bc07f and verified item by item (each fix's test goes red with the fix reverted); batch green on train #3329.

[vybe]

merge-train: batch validated on train/20261007-0858 (train #3329, green)