eve

Summary Extends eve's existing local-subagent HITL proxy so responder-authorized approvals keep the same identity, policy ownership, OAuth lifecycle, and client events across parent/child boundaries. Identity flow The root channel still authenticates the person responding to the approval. Existing delivery routing sends that verified context to the child session: The child runs its own currently deployed response authorizer. The parent does not authorize on the child's behalf. Upward lifecycle proxy The subagent adapter now forwards these child events through the existing parent continuation hook: The parent channel receives the same event payload it would receive for a root-owned approval, so Slack/client presentation does not need separate child-specific behavior. Ownership The child session remains the canonical owner of: the pending approval request; active candidates and responder binding; the response-authorizer callback; OAuth challenge/callback state; candidate audit history and terminal settlement; eventual tool execution. The root session owns only routing and user-facing presentation. Local and remote agents Local subagents use eve's capability-protected durable continuation hooks, so verified delivery auth can be forwarded without a new trust protocol. Remote agents are intentionally unchanged. They continue to require the existing opt-in and receiver-side validation. This PR does not let a remote parent assert approval on behalf of a child. Depends on #1371. Validation Validated with: focused subagent adapter, authorization proxy, HITL routing, and turn-workflow tests

Summary Exposes the authorized-approval lifecycle to channels and clients, and updates Slack to react to durable candidate/settlement state instead of treating an inbound click as final approval. Public events This PR adds two credential-free stream events: reports one responder's attempt without changing shared approval state. is the terminal signal clients use to remove/replace shared controls. Candidate OAuth continues to use the existing authorization events, now correlated to the candidate: Slack integration The Slack adapter reacts to new framework events: → sends “Checking whether you can approve this action…” ephemerally to the candidate's Slack user; → sends the for rejection ephemerally; → sends the OAuth challenge ephemerally/privately; → updates the approval card to remove controls, attributing the approver/canceller The Slack click no longer updates the approval card optimistically, since we have to wait for the authorization process. Depends on #1370. Validation Validated with: focused protocol, message reducer, Slack defaults/interactions, delivery, authorization, and tool-loop tests

Summary This PR is the bulk of approval authorization logic. Introduces state machine for approval responses using the / approval API introduced in #1559. This PR keeps approval state separate from conversation history. It records approval attempts, OAuth challenges, approval attempt outcomes, and the final approving or cancelling actor. This is necessary to enable nice multiplayer behavior, especially with blocking e.g. OAuth in the loop. Durable lifecycle Approval coordination runs in durable phases: If a responder needs to sign in, eve parks the candidate through the existing lifecycle. A callback resumes the same attempt. State machine This PR does not contain Slack presentation or public candidate/settlement events; those are layered in #1371. Depends on the approval response API PR: #1559. Validation Validated as part of the consolidated stack with: focused candidate, batch, expiry, OAuth, dynamic-tool precedence, Cancel ordering, input-request, and tool-loop tests