Closes #n does not fire when the Gitea push-mirror delivers a commit to GitHub before the direct push #3

Seen in rex/outageforge, 2026-10-01: commit bf5e9eb carried Closes #80. The post-commit hook pushed origin (Gitea) immediately; Gitea's push-mirror delivered the commit to GitHub seconds later; the session's own git push github main was then rejected ("cannot lock ref … is at bf5e9eb but expected 3f7f6b1" — GitHub already had it). Result: GitHub never processed the keyword and #80 stayed open on the Rivendell board until closed by hand. The seven other Closes trailers that night, whose direct pushes landed first, all auto-closed.

Why it matters: Rivendell's whole completion path is Closes #n on the commit that lands on main (doctrine: nothing else can set Done). Any commit that reaches GitHub via the mirror first silently leaves its issue In Progress.

Options to evaluate (Pierce's call): (a) make the post-commit hook push GitHub FIRST, then origin — so the user-credential push always wins the race; (b) have the hook push every remote in one step; (c) a post-push check that reads the issue state and falls back to rivendell_close completed with the commit sha. (a) is the smallest change and keeps the mirror as a backup rather than a leader.