ci: run verify-stack only on push to main, not on PRs (refs #182) (#184)

## What & why

`verify-stack` now runs only on a push to `main` (a merge), not on pull requests. Every job before it (lint, k8s, build, unit, frontend, mutation) is unchanged and still runs on PRs.

**Why:** the Gitea runner shares the 15 GB lab node with the deployed stack. `verify-stack` boots the whole stack a second time inside `dind`, which is what got the runner OOM-killed (#182). Running it once per merge instead of on every PR push roughly halves how often that happens.

- `.gitea/workflows/ci.yaml`: `if: github.event_name == 'push' && github.ref == 'refs/heads/main'` on `verify-stack`, with a comment.
- `docs/runbooks/ci.md`: the job table notes "push to main only".

Refs #182

## Definition of Done

- [x] Linked Gitea issue (above).
- [ ] Failing test first. *(CI config.)*
- [x] Conventional Commits referencing the issue.
- [ ] CI green. **This PR's own run should show `verify-stack` as skipped**, which is the check for the PR half.
- [x] Docs updated (`docs/runbooks/ci.md`).

## Notes for reviewers

- **gotchas §7:** on Gitea 1.27 + act_runner 2.0.0, a `needs` job gated by a *status-function* `if` (`always()`/`cancelled()`) never leaves `waiting`. This `if` is a plain event check, so it keeps the implicit `success()` and should not hit that path. It's only proven once the first merge to `main` runs `verify-stack`. If that run sits in `waiting` with no logs, force-cancel it and revert this.
- **Policy change:** CLAUDE.md §3/§15 say the compose-up smoke test "runs in CI and gates merges". After this it runs *after* the merge, so a live-stack break shows up as a red `main` (P0 per §15) instead of a blocked PR. CLAUDE.md changes need their own issue and PR, so I left it untouched. It should be updated if this approach is kept.
- If `verify-stack` is a required status check in branch protection, remove it there too. Otherwise PRs will wait for a check that never runs.

🤖 Generated with [Claude Code](https://claude.com/claude-code)Reviewed-on: #184

.gitea/workflows/ci.yaml

@@ -207,8 +207,14 @@ jobs:
   # dispatched (gitea-actions-gotchas.md §7). Default `if: success()` dispatches normally. Cost: a
   # failing mutation ratchet now skips verify-stack instead of running it anyway; the fix-and-re-push
   # re-run exercises verify-stack, so we still get the signal.
+  #
+  # Main only, not on PRs: the runner shares the lab node with the deployed stack, and a second
+  # full stack per PR was what got the runner OOM-killed (#182). PRs still gate on every job above;
+  # the live-stack check runs once per merge. A plain event `if` keeps the implicit success(), so it
+  # is not the status-function case from gotchas §7.
   verify-stack:
     needs: [mutation]
+    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
     runs-on: ubuntu-latest
     steps:
       - uses: https://github.com/actions/checkout@v4

docs/runbooks/ci.md

@@ -21,7 +21,7 @@ and CI cannot drift:
 | `frontend` | `make frontend` → Nx lint/test/build for the four portals | pnpm + Node |
 | `k8s` | `make k8s-lint` (render + schema-check the Helm chart) → `make k8s-drift` (chart still describes the same stack as `infra/docker-compose.yml`) | pinned `helm` binary + `docker compose` |
 | `mutation` | `make mutation` → `dotnet tool restore` → `dotnet stryker` (ACL); uploads the HTML report as an artifact | .NET 10 SDK |
-| `verify-stack` | the single live-stack stage — steps: `make verify-up` (full stack up + health, the DoD smoke) → `make verify-acl` (ACL ↔ OpenZaak) → `make verify-nrc` (OpenZaak → NRC delivery) → `make down` | container engine + egress (base images, nuget, `selectielijst.openzaak.nl`) |
+| `verify-stack` | **push to `main` only, skipped on PRs** (#182) — the single live-stack stage — steps: `make verify-up` (full stack up + health, the DoD smoke) → `make verify-acl` (ACL ↔ OpenZaak) → `make verify-nrc` (OpenZaak → NRC delivery) → `make down` | container engine + egress (base images, nuget, `selectielijst.openzaak.nl`) |
 
 > **Why one `verify-stack` job, not three.** The single self-hosted runner runs jobs
 > **sequentially**, so booting OpenZaak once (instead of once per check) is the