[issue-95] ci: drop the codex-review-gate, re-verify main weekly

[vinicq]

Closes #95. Supersedes #96, which tried to repair the gate instead. The ruff fix that was in that branch is split into #97 and lands first, because main is red and that is not a CI-hygiene question.

Why delete instead of repair

I opened #96 to repair this file, and repairing it was the wrong call. The gate is a hand-written reimplementation of a platform feature:

• required_conversation_resolution in branch protection does the same job with no runner, no GraphQL query to maintain, and no copies to keep in sync across four repos.
• The gate has a structural lag its own header confesses: resolving a thread emits no event Actions can observe, so it clears on the next push or a manual re-run, not on resolution. Branch protection evaluates at merge time.
• The gate deliberately ignores outdated threads, betting that "each push re-baselines the review and Codex re-posts if the issue remains". That is an assumption about another tool's behaviour, not a guarantee. required_conversation_resolution requires resolving all of them.

The alternative was never compared against, because nobody had turned it on. The gate existed by omission rather than by choice.

What was actually broken

89 failing runs, every one with zero jobs: GitHub refusing to validate the file, not a check that fails. on: declared pull_request_review_thread, a real webhook event that Actions does not accept as a trigger.

And the origin is worth recording, because it is the sharpest lesson here. In falsegreen-js, where the same file landed, the workflow ran green exactly once, on the PR head that introduced it (5a3eed8), which declared only the three valid triggers. pull_request_review_thread was added between that head and the squash to main (6c4b84d). The edit that killed the workflow was merged having never run. A gate that had never been exercised in its shipped form guarded nothing from day one.

Independent confirmation, and a one-liner worth keeping:

gh api repos/OWNER/REPO/actions/workflows --jq '.workflows[] | select(.name == .path) | .path'

A workflow whose name equals its path is one GitHub never parsed. It flagged this repo and falsegreen-js, and stayed silent for the repos where the file is absent or fixed.

Ecosystem convergence

Repo	Outcome
falsegreen	already deleted it (65482f0)
falsegreen-skill	repaired first as a diagnostic, now being deleted
falsegreen-js	this same change, separately
robotframework-falsegreen	this PR

One mechanism across four repos instead of two.

The weekly schedule stays

Running only on push to main means a floating tool can break main while the badge stays green. ruff 0.16 just did exactly that here. schedule plus workflow_dispatch caps that window at 7 days, and it covers more than ruff: runner image changes, any floating dependency.

Follow-up, not in this PR

main here has no branch protection at all, so required_conversation_resolution has nothing to attach to yet. Enabling it is the other half of this change and lands as a repo settings change, not a commit.

Rollback

git revert restores the workflow. The repaired version is preserved on the fix/gate-trigger-and-cron branch, which stays for now rather than being deleted with the PR, so the fix is recoverable if the deletion turns out to be wrong.