[pournasserian]

Closes #2570

What

Fixes from the post-merge review of #2480, #2487, #2503 and #2512 (SEC-04, SEC-08, MCP-05).

• Calls per period: a tool call is now recorded as running before its tool runs, in the transaction that counts it, and its outcome is filled in when it ends.
  • IAgentPermissions.ClaimToolCallAsync(call) replaces CheckToolCallAsync. It holds the credential's row, counts, and records the call as running, or as refused with its agent.calls_per_period_exceeded event.
  • IToolCallLog.FinishAsync sets the outcome and duration, only while the call is still running.
  • A claim that throws, such as on a database error, rolls back with the call it recorded. The call is then appended on its own as errored, and its tool does not run.
  • ToolCallOutcome.Running is new. The column is a string, so there is no migration.
• Change sets per day: OpenAsync and a session's first operation now count inside the unit of work that stores the set, after the same hold on the credential.
• Change set reads: GetAsync and DiffAsync, so get_change_set and get_change_set_diff, refuse an agent a set it did not open with agent_not_change_set_owner. People and the system read every set.
• Refusal events: IUnitOfWork.AfterRollback(step) runs a step once the outermost unit of work ends without committing, in a unit of work of its own. A cap refusal registers its event there, so the event outlives a caller's write that the refusal rolled back.
• CONTRIBUTING.md: running calls count toward the cap, and an agent reads only its own change sets.

Why

Concurrent calls from one agent all passed the calls-per-period count, because a call was recorded only after it ran. Concurrent opens all passed the daily cap, because the count ran before the unit of work. An agent could read any change set by id. A cap refused inside a write tool's unit of work lost its security event when that write rolled back.

Choices worth a look:

• The hold is a no-op UPDATE of the credential's row, as the first write in the transaction. PostgreSQL keeps the row lock and SQLite the write lock until the transaction ends, so one agent's capped actions take turns and other agents are not held up on PostgreSQL. The count after it sees every call admitted before.
• The refusal is appended again after the rollback, on the same connection, rather than written at once on a second connection. On SQLite a second connection would wait for the write lock the caller's transaction holds. The step is dropped when the unit of work commits, so the event is never stored twice.
• A running call counts toward the cap. A host that stops mid-call leaves its call as running, and that call still counts until it falls outside the period.
• The tool's own failure still wins: if the outcome cannot be written after the tool ran, the failure is logged and the agent gets the tool's answer.
• IToolCallLog.AppendAsync now records a call whose claim failed, so every call still appears in the log (MCP-07).
• The daily cap is counted inside the unit of work, so unlike other expected failures, its refusal stops a caller's outer unit of work from committing. Today every caller returns as soon as it gets the refusal.
• Not in this PR: audit events for scope and ownership refusals (Proposal: audit events for scope and ownership refusals of agents #2569, for the maintainer to decide), and reads by other services that take a change set id, which are their lanes' work.

Tests

Integration, each on SQLite and PostgreSQL:

• With a cap of 3, 12 concurrent calls run 3 tools, and the log holds 3 succeeded and 9 refused calls.
• With a cap of 1, a call whose tool is still working is in the log as running and refuses a second call. It ends as succeeded.
• With a daily cap of 2, 10 concurrent opens store 2 sets and append 8 refusal events.
• A cap refused inside a unit of work that then rolls back keeps exactly one refusal event, and the set opened in that unit of work is gone.
• An agent reads and diffs its own set, and gets agent_not_change_set_owner for a person's set and for another agent's set. A person reads both.
• Over MCP, get_change_set and get_change_set_diff on a person's set return agent_not_change_set_owner.
• A running call gets its outcome once, and a second finish changes nothing.
• On SQLite, a call whose claim fails, made to fail with a trigger, is recorded as errored and its tool does not run.

With the hold turned off, the two concurrency tests fail on PostgreSQL. On SQLite the transaction already takes the write lock when it begins.

The full suite ran locally against a postgres:17 container as well as SQLite, and markdownlint passes. No new package and no new project reference.

Checklist

• Linked to an issue a maintainer has confirmed
• Targets v2
• Tests or docs updated where behaviour changed
• No tool-generated co-author trailers or footers