opencode-claimant: fix Codex P2s in the live session-binding functions (bind lock order, revalidate task_id qualification) #5393

Problem

Codex review of PR #5349 (record copy of the live-applied session-binding migration for issue #5001, now pm-stack/opencode-claimant/migration-0023.sql) raised two P2 findings against the live-applied function bodies. The record copy must stay byte-faithful to what was applied live, so these are fixed by a new migration, not by editing the record.

Findings (chatgpt-codex-connector[bot] on PR #5349)

1. Bind lock-order deadlock — bind_repo_task_lane_session updates the lane ledger before locking the task row, while the new binding-clearing transitions lock the task row first. A same-session bind retry overlapping park_task or another clearing transition can deadlock and abort either operation. Fix: acquire the task row FOR UPDATE before accessing the ledger in the bind function. (PR opencode-claimant: migration-0022 — clear bound session_id on requeue + bind-time claim guard (#5001) #5349 review comment 4465191796, migration file line ~425.)
2. Unqualified task_id in the revalidate release branch — revalidate_parked_tasks() declares RETURNS TABLE(task_id bigint, outcome text), so the unqualified task_id reference in the release branch is ambiguous under PL/pgSQL's default variable-conflict handling and can error, rolling back the whole sweep. Fix: alias the ledger table and qualify its task_id column. (PR opencode-claimant: migration-0022 — clear bound session_id on requeue + bind-time claim guard (#5001) #5349 review comment 4465191807, migration file line ~387.)

Acceptance

• A new claimant migration (next free number) fixes both findings against the current live function bodies (re-extract live defs first; do not trust the record copy alone).
• Lock order is consistent across bind + every binding-clearing transition.
• The revalidate release path is exercised with a parked task that still carries progress.session_id (the ambiguous branch) and completes without error.
• Applied live with before/after verification, and the record copy lands via PR referencing this issue.