fix(dispatch): scope task claim and reclaim to the owning daemon

[saucam]

The bug

Two daemons sharing one ~/.codeoid/codeoid.db steal each other's dispatch work, and the conductor is told successful work failed.

Found by driving a real conductor dispatch end to end. The worker did its job:

README.md contains one line of text: hello from the probe workdir … Nothing was modified.

The conductor was told:

task c0234348 (spawn/scout) auto-BLOCKED after 2 failed attempt(s): reclaimed: stale claim

The task was marked blocked at 11:39:21 — four seconds before the worker finished at 11:39:25.

Cause

claim_owner is a daemon boot id, and dispatchReclaimStale matched:

WHERE status IN ('claimed','running')
  AND (claim_owner IS NOT ?bootId OR claimed_at IS NULL OR claimed_at + ? < ?)

claim_owner IS NOT ?bootId cannot distinguish my own crashed run from another daemon's healthy claim. Any second daemon's ordinary 5s tick reclaimed live tasks with ten minutes of lease remaining; two ticks reached failure_limit and auto-blocked work that had succeeded.

dispatchClaimNext was worse — no ownership predicate at all:

WHERE status = 'queued' AND (not_before IS NULL OR not_before <= ?) …

So a daemon could claim and execute a task belonging to another tenant, against the rule that every query is scoped to (account_id, project_id).

This is reachable, not theoretical: local-mode.md port-scopes its token file precisely so two daemons can run on one machine.

The fix

An additive owner_daemon column (host:port), set at enqueue and required by both predicates.

Scoping reclaim to the daemon's own tasks is what makes the boot-id fast path correct rather than theft — so first-tick restart recovery is preserved rather than traded away for a lease-only rule. Port-scoped for the same reason local mode scopes its token file: the port distinguishes two daemons on one machine and survives restarts.

Pre-upgrade rows have a NULL owner: still claimable by anyone so nothing is stranded, but reclaimable only on lease expiry, so the theft can't persist for exactly the rows that predate the fix.

Verification

End to end, under the real failing condition — two fixed daemons sharing one database, same dispatch that previously auto-blocked:

★ task a4e16b99 → queued
★ task a4e16b99 → running
★ task a4e16b99 → done  digest="task a4e16b99 (spawn/scout) in …"
★ event task_done

Regression tests are real — the 5 new tests fail 3/5 against the old store, pass against the new one (verified by stashing the store change and re-running).

Suite: 2434 pass, 0 fail. Typecheck and lint clean.

⚠️ Known limit — worth knowing before merging

A daemon still running the old code ignores owner_daemon and will keep reclaiming a fixed daemon's tasks. Every daemon sharing a database must be restarted for the fix to take effect.

Confirmed the hard way: my first post-fix verification still showed blocked, because an unupgraded daemon was running alongside. The new row had owner_daemon: "127.0.0.1:7455" recorded correctly — the old daemon simply didn't consult it.

Relevance to federation

This is the same bug class as docs/federation-design.md §8.1 (machine-scoped claim), appearing today with one machine and two daemons — and it settles an open schema question there: owner_daemon (executor identity) and machine_id (routing/display) are not the same column, since two daemons can share a machine. F0 keeps machine_id as a descriptive attribute.

🤖 Generated with Claude Code