release-claim: markers with no claim record strand silently under a successful run

[evanharmon1]

Invariant

A claim's markers and its claim record are released together, or the mismatch
is reported. No close event leaves claim:* labels or an assignee standing
while the release exits reporting success.

Current violation (observed 2026-08-11/12)

release-claim.sh locates a claim solely by a comment starting Claiming —
from a trusted claimant (fetch_claim, around lines 203-232). With no such
comment it takes the .found != true branch:

echo "$repo#$issue has no trusted claim comment — nothing to release" >&2
exit 3

and claim-release.yml treats exit 3 as success. That is right when nothing
was ever claimed — but it is indistinguishable from the case where the markers
ARE set and only the record is missing, and there the claim strands silently
with a green workflow run.

Observed on evanharmon1/harmon-init#745 and #753: both closed 2026-08-11
01:58:46Z when their PR merged, both triggered claim-release.yml, both runs
reported success, and both kept claim:claude plus an assignee until they
were released by hand a day later. The retro found them only because it reads
markers directly rather than trusting run status.

The markers had been written directly (gh issue edit --add-label claim:claude --add-assignee @me) instead of through /claim, so no Claiming — comment
existed. That is a real usage path: tick-criteria.sh requires an assignee, so
setting one by hand to satisfy it is an easy way to create markers with no
record — and nothing warns.

Why this matters more than the one incident

The workflow's success is what makes it invisible. A stranded claim tells the
next session an issue is being worked on when it is not, and the only signal
that anything went wrong is a >&2 line inside a green run that nobody reads.

Verify

rg -n 'has no trusted claim comment' \
  ai/skills/universal/track-work/assets/release-claim.sh

If that branch still exits without inspecting the issue's labels and assignees,
this is open.

Proposed fix

In the .found != true branch, read the issue's labels and assignees before
exiting. If a claim:*/agent:* label or an assignee is present, the markers
outlived their record: emit ::warning:: (or a distinct exit code the workflow
surfaces as a warning) naming the issue and the markers found, so the run is
visibly not a clean no-op. Removing markers there would be wrong — without a
record there is nothing proving this session set them — but saying so out loud
costs nothing and turns a silent strand into a visible one.

Acceptance criteria

• A close event on an issue carrying claim markers but no claim record produces a visible warning naming the issue and the markers, not a silent success.
• An issue with neither markers nor a record still exits quietly, as today.
• The script still removes nothing when it cannot prove the markers belong to a claim it can identify.

Found while investigating why evanharmon1/harmon-init#745 and #753 stranded.