feat(tools): idempotency keys and execution ledger for tool calls

[gibbsie]

Summary

Event redelivery is already deduplicated, but nothing protects tool side effects. A retried node or a redelivered dispatch can create the same Jira ticket twice, for example, write the same row twice, or call the same HTTP integration twice. The governed tool handler intercepts every worker tool call, so it is the natural place to make side effects idempotent. This is the first of two PRs for this capability. Scope is deliberate and stated below.

What changed

• Deterministic idempotency key per tool call: execution id, node id, call index, tool name, and a canonical hash of the arguments. Canonicalization is pure and property-tested, including two hazards that silently break determinism: non-string dictionary keys (which raise under sorted serialization) and integral-float / negative-zero collapse.
• Tool-execution ledger: a new org-scoped DynamoDB table keyed orgId#executionId / nodeId#calLIndex#toolName#argsHash, with a 48-hour TTL. It is an operational dedupe record, explicitly not an audit artifact - the governance ledger remains the audit trail.
• Reserve → execute → finalize at one atomic seam: a single
  'selected_tool' swap in the governed handler, all three steps inside one coroutine. There is no pre/post-hook window in which a side effect could run outside the protocol. A completed key returns the recorded result instead of re-executing.
• Concurrent-caller safety: the reservation is a conditional write. The loser never executes - it polls for the holder's result within a hard bound, then returns a retryable no-execution error. A crashed holder is reclaimed via a conditional compare-and-set so a key cannot wedge forever.
  Fail-safe failure semantics: an un-tokened call whose outcome is unknown is recorded as indeterminate, refused for re-execution, non-retryable, and surfaced - never silently retried (which would guarantee a duplicate) and never swallowed.
• Protected by default: a tool with no classification flag is treated as side-effecting and goes through the ledger. Bypass requires an explicit flag, and a bypass flag on a demonstrably side-effecting tool blocks under strict enforcement rather than warning.
• Context threading: execution id, node id, and org id now reach the handler. Org id is read server-side from the execution row and never trusted from a subprocess payload.

Guarantee (stated precisely)

Exactly-once within an attempt, plus safety under concurrent callers of the same key. This is not once-across-re-dispatch: if the watchdog re-dispatches a stalled node and the agent body replays nondeterministically, the keys differ and the ledger cannot absorb the duplicate. Closing that requires the dispatch-generation fence, which lands in future work, next - the code and docs say so explicitly so this PR isn't mistaken for the complete guarantee.

Testing

• Forced double-delivery of a ticket-creating call (stubbed adapter, real conditional write): exactly one execution and one recorded result.
• Hypothesis property test driving the execution path: for arbitrary arguments, two calls with the same key produce exactly one adapter invocation and completed row.
• Concurrent-reservation race with a recorded red proof - a non-conditional reserve lets both callers execute; the conditional reserve lets exactly one.
• Canonicalization properties, dead-holder reclaim, TTL and org-scope isolation, protected-by-default classification, strict-mode block on a mis-flagged tool.
• Arbiter pytest and full backend suite green (6,806 tests); tsc clean; synth clean; ledger grant scoped to a single table ARN.

Deployment notes

Adds one DynamoDB table with TTL and a scoped grant. No schema changes. Work follows in this same capability: dispatch-generation fence, S3 offload for oversized results, and client-token passthrough for targets that support it.