Scope the Stop-hook fix loop to the session that made the commit

[martingtobias]

Problem

With two Claude Code sessions open in the same repo, a FAIL review triggered by session A also blocks session B on Stop. B receives:

Fix the issues identified in the review and commit them -- amend the reviewed commit if it has not been pushed…

…for a commit it did not make. Meanwhile session A is very likely still working those same files with uncommitted changes. Following the instruction means editing a file another agent holds live edits in, and --amend-ing that agent's commit out from under it.

I hit this for real: a second session was told three times to amend another running session's unpushed commit, with that session's server/routes.ts dirty at the time.

Fix

post-commit-review.sh runs as a PostToolUse hook, so it already receives the harness JSON and knows which session made the commit. Record that session_id as a fourth field on the FAIL state; the Stop hook then blocks only when the state is unowned or owned by the current session.

Two details that matter:

• A non-owning session stays completely inert — no block, and it does not touch the state file or the loop counter, both of which the owning session is still using. Clearing either would silently reset the owner's fix loop.
• Ownership is checked after the existing staleness rules, so an abandoned session's state still self-clears for anyone via the one-hour cap. Ownership can't wedge state.

Compatibility

State written before this change — or by a commit made outside a Claude session — carries no session id. That disables the check and preserves current single-session behaviour exactly. Same when the harness supplies no session_id.

Tests

tests/helpers.bash gains an optional trailing session_id argument on hook_input and stop_input; omitted means the key is absent from the JSON, so every existing test exercises the unstamped path unchanged.

Seven new cases:

• FAIL owned by another session: no block, owner's state and counter untouched
• FAIL owned by this session: still blocks and increments
• session-stamped FAIL blocks a session that reports no id
• unstamped FAIL blocks any session (pre-upgrade state)
• stale FAIL owned by another session is still cleared
• FAIL state records the session that made the commit
• FAIL state omits the session field when the harness supplies none

bats tests/ — 56/56 pass (1 pre-existing skip: coreutils timeout not available on this machine).

[andreidavid]

Exactly the fix this needed. The details are all right: ownership checked after the staleness rules so state can't wedge, the state format compatible in both directions, and a non-owning session staying fully inert instead of touching the owner's counter. The test coverage is exemplary — every edge case I went looking for was already there, including "non-owner leaves the counter untouched" and "unstamped pre-upgrade state still blocks". Thanks for the careful diagnosis and the writeup; this was a pleasure to review. Merging.