check_issues blocks wrap-up on a since-RELEASEd issue another session re-CLAIMed nf-9xf ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/1130 by tools/beads/import_github.py's reconcile pass.

nflib.sessions.check_issues blocks wrap-up when an issue whose comment history mentions this session's sid has, as its LATEST CLAIM/RELEASE marker, a CLAIM — without checking WHOSE CLAIM it is.

Reproduced live, 2026-08-19, nf-dev-011-sync: I posted CLAIM session=011-sync sid=... on #1122, then RELEASE session=011-sync sid=... minutes later (reassigned to a fresh session per Aedan). Session 011-sharedbd then posted its OWN CLAIM session=011-sharedbd ... on the same issue to pick it up. ./dev.py wrap now refuses with #1122 (CLAIMed by 011-sharedbd) — correctly identifying the current claimant, but still treating it as MY session's open/held work and blocking --remove.

check_issues (tools/nflib/sessions.py:1307-1350) finds #1122 as a candidate via _issues_naming_sids (my sid appears in my own CLAIM/RELEASE comments), then checks only whether the latest marker .startswith("CLAIM") — never comparing _claimant(marker) against session.label/session.sids. So a clean RELEASE followed by a DIFFERENT session's CLAIM still reads as "held" by the releasing session.

Fix, roughly: when the latest marker is a CLAIM, only treat it as held if _claimant(marker) matches this session (or the label check already caught it) — a CLAIM by a different, later session should count the same as a RELEASE for the purposes of THIS session's wrap-up.

Filed unclaimed. Worked around this run by reporting status manually rather than forcing --remove (no override exists for this check, deliberately, per the file's own docstring).