docs(ci): correct the merge-ref claim; PR CI tests the head tree

My own comment asserted 'PR CI tests the merge ref, whose tree equals the
landed squash commit' - never measured. Pipeline API refs show pull_request
runs execute refs/pull/N/head (2542, 2545): the head tree, not a merge ref.
If next advances between run and merge, the landed tree differs from the
tested one; that residual is what publish verify re-covers post-merge (full
verify:release on the push, PGlite path). Same evidence discipline this PR
exists to enforce; the claim is corrected to what was measured.

.woodpecker/ci.yml

@@ -12,12 +12,12 @@ when:
   # Push CI runs on main only. next deliberately runs NO push ci: post-merge
   # verification on next is carried by publish.yml's `verify` step
   # (pnpm verify:release), which mirrors this pipeline's complete mandatory
-  # set step-for-step, enforced by scripts/verify-release.test.mjs. The two
-  # things push-to-next does not re-run, the postgres-path test and a
-  # push-ci status context, duplicate pre-merge coverage: PR CI tests the
-  # merge ref, whose tree equals the landed squash commit. Measured
-  # 2026-08-19: the 21 most recent push events on next each ran exactly one
-  # pipeline (publish), zero ci.
+  # set step-for-step, enforced by scripts/verify-release.test.mjs. PR CI
+  # tests the PR HEAD tree (refs/pull/N/head, measured 2026-08-19), not a
+  # merge ref, so if next advances before a merge the landed tree differs
+  # from the tested one; publish verify re-runs the full set on the landed
+  # tree (PGlite path). Measured 2026-08-19: the 21 most recent push events
+  # on next each ran exactly one pipeline (publish), zero ci.
   # Keeping push ci off next also avoids a redundant second full-suite run
   # per merge on the storage-constrained runner.
   - event: [pull_request, manual]