fix(ci): a check that never starts, and a contract that never moves

[euskadi31]

engine.md section 11.4 gained two requirements after #9 was written. Both were
measured by other engines; both are defects in what #9 shipped.

The required check would never have started

A pull request opened with a repository's own GITHUB_TOKEN starts no
pull_request workflow — GitHub cuts there so an action cannot call itself in a
loop. #9 armed auto-merge behind a branch protection requiring Verify, and
Verify comes from ci.yml, which would never have run on a synchronization
pull request. Every synchronization would have sat at mergeStateStatus: BLOCKED
forever, waiting for a check with nothing to start it.

The workflow already runs the section 12.5 entry point. It now publishes that
result as the Verify commit status on the head it just pushed:

gh api -X POST "repos/$repo/statuses/$(git rev-parse HEAD)" \
  -f state=success|failure -f context=Verify ...

Same definition of green, same name the protection requires, no second workflow
recomputing it, and no token wider than statuses: write on the repository's own
commits. Measured on this branch's head: the POST succeeds and
GET /commits/{sha}/status reads it back as state: success.

The prose contracts travel with the release now

spec.md, engine.md and engine-swift.md became release artefacts in spec#87,
listed in SHA256SUMS and covered by the attestation this workflow already
verifies. #9 excluded them, on the then-correct ground that the release did not
publish them. Section 11.4 step 3 now names them, and the reason is the one the
Go engine gave: an engine that fetched only the data would keep a stale contract
and would not notice, because nothing digests them.

Still open, and still measured

• The provenance writer is still not a release artefact, and neither are its
  templates. docs: the one file of section 11.4 step 3 the release does not carry #10 records it.
• Allow GitHub Actions to create and approve pull requests is still off, and
  it is refused at the repository level with "The organization does not allow
  GitHub Actions to create or approve pull requests". Until an owner checks it
  for the libbusinessid organization, a synchronization reaches step 6 and dies
  there with that instruction printed, its branch pushed.

[euskadi31]

One more guard, made real rather than advisory.

GITHUB_TOKEN cannot read a branch's required checks — measured: actionlint
lists every permission scope a workflow may request and there is no
administration among them. So the first auto-merge condition was only a printed
note.

It is not the whole condition, but whether main is protected at all is readable
with the token already in hand: .protected is a field of the branch object.
Measured on this repository — main answers true, chore/rules-2026.08.25
answers false. The script now refuses to arm auto-merge when it answers false,
because that is precisely the case where auto-merge merges at once, green or red.
Which checks are required is still attempted and its refusal reported, not
treated as an answer.