Closes the findings of a third independent review of the tool boundary and builds the pending-action package of the actions design on top. Guarantees: - A pending action is confirmed or cancelled once, by exactly one request, on one server or several: the decision is an insert under a unique key (new table assistant_pending_action_claim). Whatever fails after the claim ends in FAILED or EXECUTED with a tool-call row, never in RUNNING. - A tool cannot be run around the tool-call service from code outside the assistant's packages: execute, log and withdraw are package-private; a tool call request, a confirmed tool call and a tool context have no public constructor and are made only with the service's permit; the runtime has no public getter for the tool registry, the UI API gateway or its tool families. A host's own ToolFamily and AssistantTool compile unchanged. - A signed-in person is one person: a session with no HTTP request is made a person only when the authentication module resolves the session's own id to the user the session names. The turn engine no longer makes a person. - Only the credential a request's session was resolved from is forwarded to the UI API. - A tool call that was cut short leaves no proposal anybody could confirm. - The policy a tool call runs under is read fresh on every call. - The hard budget is read on every call with one aggregate query per budget. - The input kept in the tool-call log is redacted with the administrator's custom patterns too. Pending actions (design package A3): - update_record and delete_record read the record as the person when they propose; the card shows each field before and after (a delete: what the record holds), after the exposure rules of get_record. - What was approved is what is written: the proposal keeps a version of the record (a digest, never values); a confirmed update or delete reads the record again and refuses when it changed, is gone or cannot be read. - actionKind (record_create, record_update, record_delete, or the proposing tool's name), GET /assistant/actions (the person's own list), and approvalRetentionDays is now read by the retention process. - UI API extension assistant 1.9.0 (additive). Schema: three columns and two indexes on assistant_pending_action, and the table assistant_pending_action_claim (docs/schema-postgres.sql, UPGRADE.md). ChatToolSetTest and ToolCallChecksTest pass unchanged. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>