fix: don't cancel in-flight :latest builds on release-please's follow-up push

[StrandedTurtle]

Summary

• Root cause of a live production issue: after merging feat: show layer age in prune table #73, GHCR's :latest tag ended up built from the pre-release-bump commit (d570b1f), not the actual release commit (d662b93, chore(main): release 1.6.0). Confirmed by comparing GHCR manifest digests directly: :latest = sha256:f7178f2..., :1.6.0 = sha256:ec3377c... — different builds. The :1.6.0/:1.6 pinned tags are correct; only :latest was stale.
• Cause: release.yml's concurrency: cancel-in-progress: true treats every push to main as competing for one publish-refs/heads/main slot. release-please auto-merges its release-bump PR seconds after a feature merge, so two pushes race for that slot — and in this case the newer (release-bump) push's build got cancelled by the timing of the older one, leaving :latest stuck on pre-bump content with no visible failure anywhere (the run just shows "cancelled", easy to miss).
• Fix: cancel-in-progress: false. Both runs now queue and complete in order instead of one killing the other, so :latest always ends up built from whichever commit landed last on main. Also refreshed a stale comment in the same file describing an old dispatch-based flow that no longer exists (release-please.yml now relies on its PAT-authored tag push directly).
• This PR's own merge will itself push to main and rebuild :latest from current main (already at 1.6.0), fixing the live GHCR tag as a side effect of merging.

Test plan

• Diagnosed via GHCR manifest digest comparison (ghcr.io/v2/strandedturtle/dockpull/manifests/latest vs /1.6.0)
• Confirmed via GitHub Actions run history: the Publish image run for d662b93 (head_branch main) is cancelled; the tag-triggered run for v1.6.0 succeeded independently
• After merge: confirm the new Publish image run for main completes (not cancelled) and :latest's manifest digest matches :1.6.0's

---

Generated by Claude Code