Tracking Issue: deliver interoperable Agent-to-Agent Handoff

Feature description

Define a host-neutral delivery contract that lets one supported Agent integration hand exact work to another through PowerContext.

PowerContext already has Work Contracts, immutable Handoff Revisions, evidence re-resolution, acknowledgement, Task Outcome, a versioned integration capability manifest (#1357), and a deterministic cross-host acceptance scenario (#1358). The missing product layer is how a sender selects a receiver, how the exact Handoff reaches that receiver, and how delivery state remains observable when the receiver is offline, incompatible, or unauthorized.

Parent roadmap: #1352.

Problem and proposed solution

The repository contains multiple Agent and framework integrations, but the number of integration directories is not an interoperability contract. A user should not have to copy a Handoff identifier between terminals or expose the sender's Session transcript to continue work in another Agent.

The RFC should define one Server-mediated exchange flow:

1. The sender selects an exact Project/Workstream and a receiver target derived from #1357 rather than a hard-coded host list.
2. PowerContext prepares and commits one immutable Handoff Revision.
3. The sender requests delivery to an explicit receiver identity or enrolled target.
4. The receiver integration discovers or pulls a bounded delivery envelope.
5. PowerContext re-resolves the exact Handoff and evidence under current authorization.
6. The receiver records accepted, needs_clarification, or declined for the exact Revision.
7. A later Task Outcome covers only the exact accepted Receipt.

The design should decide:

• receiver identity, enrollment, discovery, and target selection;
• push, pull, or hybrid delivery semantics, including offline receivers;
• a versioned delivery envelope distinct from Handoff content and Handoff Receipt;
• idempotency, expiry, retry, cancellation, duplicate suppression, and dead-letter behavior;
• capability and version negotiation using #1357;
• current-head, evidence-availability, workspace-drift, and authorization checks;
• delivery status and content-free diagnostics for CLI, Dashboard, and integrations;
• compatibility with the access-control boundary in #1395;
• how Project/Workstream decisions from #1219 constrain cross-Workstream delivery.

The first implementation should qualify one sender/receiver pair, then expose conformance fixtures that other maintained Agent hosts can adopt without requiring identical hook names, commands, or tool surfaces.

Acceptance criteria

• One supported Agent can deliver an exact Handoff to another without sharing the sender's Session transcript.
• Delivery is idempotent and observable across receiver-offline, incompatible, expired, revoked, and unauthorized cases.
• The receiver cannot acknowledge latest; it acknowledges one frozen Revision after exact evidence re-resolution.
• An unavailable or drifted Handoff cannot silently trigger the old next action.
• Delivery and acknowledgement do not grant tools, network access, credentials, deployment authority, or permission to execute.
• accepted remains receiver acknowledgement, not proof of completion.
• HTTP, MCP, Dashboard, and host adapters preserve the same delivery and authorization semantics.
• The acceptance report records exact PowerContext, integration, envelope, and policy versions.

Alternatives considered

• Copy complete Session transcripts: loses authority boundaries, increases privacy risk, and makes continuation host-specific.
• Require direct peer-to-peer connectivity between every Agent pair: creates an N-by-N transport and credential matrix.
• Use A2A or another protocol as the domain model: an adapter may be added later, but PowerContext still needs its own exact Handoff, evidence, acknowledgement, and authorization semantics.
• Build a multi-Agent orchestrator: out of scope. PowerContext delivers context; it does not choose Agents or automatically execute work.

Additional context

Related issues: #1352, #1357, #1358, #1362, #1395, and #1219.

• I am willing to contribute code, docs, or design feedback.

The issue names no files or tests; begin by reading related issues #1352, #1357, #1358, #1362, #1395, and #1219 to understand the existing contracts and authorization boundaries. Define the server-mediated delivery contract and qualify one sender/receiver pair; done means the listed acceptance cases are observable, idempotent, authorization-safe, and covered by conformance fixtures.