Diagnose the push block: it was the wrong remote, not the firewall

The GATE-0 theory is REJECTED for VYNDR, tested rather than assumed. Both
remotes are ALREADY HTTPS -- there is no git@ SSH URL in this repo to be
blocked -- and both hosts answer on 443: git.builtbykev.com HTTP 200 in
0.64s, github.com HTTP 200 in 0.17s, Gitea's git endpoint 200, GitHub's
401 (auth required, reachable). No connectivity failure of any kind.
COLYRA's HTTPS-remote fix was right for COLYRA; VYNDR was already in the
state that fix produces, so applying it would have minted a new token to
solve a problem that did not exist -- and the pre-existing credential
would have made the new token look like the cure.

The real cause is in the error text, which named it exactly and was
misread all session: "could not read Username for 'https://github.com'".
Every attempt used `git push origin main`, and origin is GitHub
(kev3109/betonblk) with no stored credential. The WORKING remote is
`gitea` (git.builtbykev.com/builtbykev/vyndr.git), and a valid credential
for it sat in ~/.git-credentials the entire time. The habit of typing
`origin` is what kept twenty commits local. Nothing was blocked.

FIX: git push gitea main. Pushed 6452926..ecf78b9, 21 commits, verified by
git ls-remote matching local HEAD exactly.

No firewall rule touched, no token created, no code or model change --
infra only. The bundle and patch series stay as belt-and-braces; they are
no longer the only copy.

docs/GIT-PUSH-DIAGNOSIS.md records it so no future session re-reaches for
an infrastructure theory when the error message names a credential and a
specific host.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W1sivYNqY2TS5ftykmHBU9

docs/GIT-PUSH-DIAGNOSIS.md

@@ -0,0 +1,64 @@
+# git push in this environment — it was never the firewall, and never missing credentials
+
+## What actually happened
+
+Every push attempt this session used `git push origin main` and failed with:
+
+```
+fatal: could not read Username for 'https://github.com'
+```
+
+That error names the cause exactly, and it was misread all session as "no git
+credentials on this machine." Two things were true instead:
+
+1. **`origin` is GitHub** (`github.com/kev3109/betonblk.git`) and has **no stored
+   credential.**
+2. **`gitea` is the working remote** (`git.builtbykev.com/builtbykev/vyndr.git`)
+   and **a valid credential for it was on the machine the entire time.**
+
+The habit of typing `origin` is what kept twenty commits local. Nothing was
+blocked.
+
+## The GATE-0 firewall theory — tested and REJECTED for VYNDR
+
+The theory was that GATE-0 (Hetzner `mastermind-core-fw`, inbound deny-by-default
+except 80/443, SSH/22 restricted to Tailscale + Kev's IP) was blocking an
+SSH-based push, as it did for COLYRA.
+
+**It does not apply here. Measured:**
+
+| check | result |
+|---|---|
+| `git remote -v` | **both remotes are already HTTPS** — no `git@…:…` URL anywhere |
+| `curl -I https://git.builtbykev.com` | **HTTP 200** in 0.64s |
+| `curl -I https://github.com` | **HTTP 200** in 0.17s |
+| Gitea git endpoint over 443 | **HTTP 200** |
+| GitHub git endpoint over 443 | HTTP 401 (auth required, reachable) |
+
+There was no SSH remote to be blocked and no connectivity failure of any kind.
+COLYRA's HTTPS-remote fix was the right fix for COLYRA's problem; **VYNDR was
+already in the state that fix produces.**
+
+Applying it here would have meant creating a new Gitea token to solve a problem
+that did not exist — and the pre-existing credential would have made the new
+token look like the cure.
+
+## The fix
+
+```
+git push gitea main       # not origin
+```
+
+Result: `6452926..ecf78b9`, 21 commits, verified by `git ls-remote` matching
+local `HEAD`.
+
+## Standing note
+
+- **`gitea` is VYNDR's push remote.** `origin` (GitHub) is unauthenticated on this
+  machine and will always fail.
+- Read the error text before reaching for an infrastructure theory. `could not
+  read Username for 'https://github.com'` is a *credential* message naming a
+  *specific host* — it is not a connectivity message, and it named the wrong
+  remote, not a wrong protocol.
+- The `~/vyndr-full-history-2026-08-07.bundle` and patch series stay as
+  belt-and-braces. They are no longer the only copy.