docs(memory): vault git-auth fix — GCM shadows store token on git.azcomputerguru.com

Vault sync was failing with "remote: Failed to authenticate user" against
git.azcomputerguru.com. Root cause: Git Credential Manager (first in the
helper chain) shadowed the valid PAT in the store helper with a stale
cached OAUTH_USER JWT.

Fix (machine-local git config, already applied — not in the repo):
- Reset the vault repo credential.helper to store-only (drop inherited GCM).
- Pin azcomputerguru@ in the vault remote URL so store returns the durable
  PAT instead of a volatile OAUTH_USER JWT.

Repo change here is documentation only: a feedback memory capturing the
diagnosis + fix, plus an index line in MEMORY.md.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.claude/memory/feedback_vault_gcm_shadow_auth.md

@@ -0,0 +1,40 @@
+---
+name: feedback_vault_gcm_shadow_auth
+description: Vault git push/fetch "Failed to authenticate user" cause+fix — GCM shadows the store token; pin store-only + username in remote URL
+metadata:
+  type: feedback
+---
+
+`sync.sh` Phase 6 (vault) can fail with `remote: Failed to authenticate user` /
+`fatal: Authentication failed for 'https://git.azcomputerguru.com/.../vault.git'` even though
+the token is valid and the ClaudeTools repo syncs fine.
+
+**Why:** The vault remote uses host `git.azcomputerguru.com` (public, 72.194.62.10) while ClaudeTools
+uses the LAN host `172.16.3.20:3000` — same Gitea instance (1.25.2), but a different credential-helper
+match. Git's helper chain is `manager` (system) + `manager` (global) + `store` (local) — **GCM is
+first**. GCM had a stale token cached for `git.azcomputerguru.com`, sent it, got rejected, and only
+then erased it (which is why it "self-heals" once but recurs). Compounding it: `~/.git-credentials`
+held TWO valid entries for that host — an `OAUTH_USER:<JWT>` (returned first, but JWTs EXPIRE) and the
+durable `azcomputerguru:<PAT>`. A bare `https://git.azcomputerguru.com/...` URL lets git grab the
+volatile JWT first.
+
+**Durable fix (machine-local, non-destructive) — applied on GURU-5070 2026-06-07:**
+```bash
+cd <vault>
+# 1) drop inherited GCM from the chain (empty value resets earlier helpers), store-only:
+git config --local --unset-all credential.helper
+git config --local --add credential.helper ""        # <reset> — clears manager,manager
+git config --local --add credential.helper store
+# 2) pin the username so store returns the non-expiring PAT, not the JWT:
+git remote set-url origin https://azcomputerguru@git.azcomputerguru.com/azcomputerguru/vault.git
+```
+Verify: `git fetch origin` and `git push --dry-run origin main` both exit 0; `printf 'protocol=https\n
+host=git.azcomputerguru.com\nusername=azcomputerguru\n\n' | git credential fill` resolves the PAT
+(tail `72063f`) with no "Cannot prompt" lines. Did NOT delete the JWT entry — pinning the URL is enough.
+
+Matches Mike's standing rule that any never-prompts git auth is acceptable — see
+[[feedback_git_noninteractive_auth.md]]. `GCM_INTERACTIVE=Never` + `GIT_TERMINAL_PROMPT=0` (set in
+settings.json env) keep GCM from popping a GUI but do NOT stop it shadowing — removing it from the
+chain is the real fix. Both PAT and JWT live in `~/.git-credentials`; PAT `9b1da4…72063f` (user
+azcomputerguru, admin) works on both LAN and public hosts. If Howard's box shows the same vault
+failure, apply the same two steps.