ci: gate merges on the test check, and verify the merge result

[eaitbrahim]

Adds push: branches: [main] back to ci.yml, keeping workflow_dispatch.

on:
  push:
    branches: [main]
  workflow_dispatch:

Why this is not the redundant run it was called in #200

#200 removed this trigger on the grounds that it re-ran content the pull_request run had already passed. That reasoning held while pull_request still existed. It does not now — #234 removed it, so nothing automatic runs at all.

It was also incomplete even then. A pull_request run tests the PR head; a push run tests main after the merge landed. Those diverge whenever two independently-green branches conflict semantically — each passes alone, the merge of them does not. Only the post-merge run observes the tree that actually resulted.

What this does and does not buy

Does: every merge is verified within minutes, against the real post-merge tree. Given three PRs in this repo have merged mid-flight while an agent was still pushing to them (#192, #218, #235), time-to-discovery is the practical problem, and this addresses it.

Does not: block a merge. It runs after. Blocking needs two things this repo lacks, and they must move together:

1. a pull_request trigger, and
2. a ruleset that actually matches main and requires the test context.

The ruleset named main exists but matches no refs (ref_name.include is empty; GET /rules/branches/main returns []), and its required contexts ("Lint, Unit tests, Build", "Integration Tests") match no job here. Pointing it at main without fixing the contexts would block every PR forever on checks that can never report. Tracked in #236.

release.yml is unchanged and remains the gate that matters for money — it re-runs ruff + pytest before building an artifact, so a red main still cannot ship.

Concurrency

Unchanged (ci-${{ github.ref }}). The comment is updated: back-to-back merges to main now cancel the older run, which is correct — the newest main is the only one whose result still matters.

Validation

• YAML parses; triggers read {'push': {'branches': ['main']}, 'workflow_dispatch': None} (checked via d[True], since PyYAML follows YAML 1.1 where bareword on is boolean).
• actionlint clean, exit 0.
• Job steps untouched — the diff is triggers and comments only.

[eaitbrahim]

Amended: added pull_request alongside push: [main].

on:
  pull_request:
  push:
    branches: [main]
  workflow_dispatch:

This PR is now half of the #236 fix and must merge first. The other half — repointing the main ruleset at the branch and swapping its two phantom contexts for test — can only be applied once this is on main, or the required check would never report and every PR (including this one) would deadlock.

The context string is test because the job is test: with no name:; confirmed against a real completed run on #220, which reported exactly test. That coupling is now written into the workflow comment, since renaming the job would silently break the ruleset.

actionlint clean; triggers parse as {'pull_request': None, 'push': {'branches': ['main']}, 'workflow_dispatch': None}. Concurrency comment corrected — PR runs key on refs/pull/<n>/merge, so they never cancel the post-merge main run.