drift: release + verify skills predate carried-forward releases (wrong trigger, existence-only step 40)

[elronbandel]

Which rule

• Document: .agents/delivery/release/SKILL.md + .agents/verification/verify/SKILL.md
• Rule number / section: release skill step 7 (CI builds the fleet); verify skill step 40 (verify images published)
• Rule text (pasted verbatim):

7. Prefer letting CI build the fleet. .github/workflows/release-images.yml runs bake on every push to main (tag: latest) and every v* tag …
8. Verify images published — docker pull …:eval-vX.Y.Z for each. Pass = every expected tag exists.

Evidence of drift

• File: both skills predate the carried-forward system (rules(delivery): carried-forward releases — retag unchanged images instead of rebuilding #293 → feat(release): carried-forward retag — unchanged images keep their digests #307, all merged).
• What the code does now: the fleet workflow triggers on tags + workflow_dispatch (never a plain main push); it rebuilds only images whose eval.input-hash changed and retags the rest from the prior release (delivery rules 12–14, live-proven in run 31363843159); force_rebuild/rebuild_bases cover CVE refreshes; freshness is auditable via fleet-status.
• What the docs say: step 7 describes a push-to-main trigger that does not exist and an unconditional full rebuild; step 40's pass criterion is tag existence only — it cannot distinguish a correctly carried-forward digest from a stale one, even though the tooling to check now exists.

Expected fix direction

• Update the code to satisfy the rule (here: update the procedure docs to match the shipped behavior — the skills are the walkable procedures, so their steps must describe the real release)

Scope

• Single artifact
• Fleet-wide (the release/verify walk applies to every release)