fix: find the build's commit instead of demanding it be HEAD

[cshuttle]

Found on first contact with a real repo, exactly where I expected the workflow to be wrong.

The bug

The guard demanded the promoted digest be tagged with the ref HEAD sha. But build workflows carry paths filters, so a docs- or CI-only commit moves the branch without producing an image. From that moment the repo is unreleasable until someone touches a build input — which is absurd, and Topology triggers it immediately: adding its release workflow is itself such a commit.

The fix

Walk back from the ref and find the most recent commit whose per-commit tag carries this digest. This keeps everything the old check bought — the image provably came from this branch, not a stale build or another branch — and answers a question the first version never asked: which commit is this image?

The git tag is then created on that commit rather than HEAD, so a version names code that is actually in it. Usually identical; when they differ, this is the honest one. The tag message and job log both record how many commits the ref moved on afterwards.

Also guards the multi-image case: images released together must resolve to the same build commit, or the release fails rather than quietly shipping a mismatched pair.

Cost

One crane ls per image up front, then membership is a local grep -Fxq. Topology already has 65 tags, so the naive alternative is a registry round trip per commit per tag form.

Verified against the live registry

scenario A — ref HEAD is the built commit:
  origin/main -> built from 177655b, 0 behind
scenario B — ref HEAD is a CI-only commit on top (previously a hard failure):
  feat/release-workflow -> built from 177655b, 1 behind

New verify-depth input (default 50) bounds the search; it needs to cover the gap between HEAD and the last commit that changed a build input.