ci: run the gate before the deploy, not after it (#70)

* ci: run the gate before the deploy, not after it

master is the live branch — every app fetches its config from
raw.githubusercontent.com/.../master/... — and the flow was arranged so that content
reached it first and was checked afterwards.

auto-pr.yml fired on a push to *master* and opened a master → main PR. Code Quality ran
on that PR, i.e. on the way into the mirror, long after the config was already being
served. A check that reports "the live config is broken" is not a gate.

The same inversion made master unwritable by the front door: five required status
checks, and no workflow triggering on a PR into master, so the only way to change the
live branch was to bypass its own protection. That is not a hypothetical — it was
bypassed twice on 2026-08-10, and the second time was to undo the first.

Now: work lands on main, Code Quality decides, and promote-to-live moves master to the
exact commit that passed. It refuses anything that is not an ancestor of main, and uses
--force-with-lease so a master that moved underneath it is a failure rather than a
silent overwrite. main already ran Code Quality on push, so no trigger change is needed.

Also: each daily sync opened a PR and nothing closed the previous one. Thirty-one
branches spanning 2026-02-10 to 2026-08-08 were cleared by hand on 2026-08-11, every one
superseded by the next day's run. A sync is a snapshot of upstream, so an older open
sync PR is never the right thing to merge — it is noise that hides whether anything is
genuinely waiting. The sync now closes what it supersedes.

Branch protection still needs moving in the same direction and cannot be done from a
commit: main requires no PR, no approvals and no checks, while master carries the five
checks that can never run there. The settings change is proposed separately.

* ci: require an admin's approval before anything reaches the live branch

main is where work lands and where Code Quality decides; promote-to-live then moves
master to whatever passed, and every app reads master directly. An approval on main is
therefore the last human judgement before a change is served to wallets in the field —
and until now main required no review at all.

One approval, from either admin. Requiring two would mean two of two, which stalls
whenever one of them is the author.

.github/CODEOWNERS

@@ -0,0 +1,14 @@
+# Who has to approve before anything reaches the live branch.
+#
+# main is where work lands and where Code Quality decides; promote-to-live then moves
+# master to whatever passed, and every app reads master directly. So an approval here is
+# the last human judgement before a change is being served to wallets in the field.
+#
+# One approval is enough, but it has to come from one of these two. Requiring two
+# approvals would have meant requiring two of two, which stalls whenever one of them is
+# the author.
+#
+# Read-access collaborators cannot approve, so adding a reviewer here also means giving
+# them write access.
+
+*       @SatoshiQaziMuhammed @QaziMuhammedKochgiri