Bilateral trust agreement protocol for cross-enterprise federation

**Labels:** `enhancement`, `federation`, `feature-request`, `discussion`

### Context

The registry supports federation today — [ARD ingestion](https://github.com/agentic-community/mcp-gateway-registry/blob/main/docs/ard.md#3-federation--ingest--cross-reference-other-registries), [AgentCore sync](https://github.com/agentic-community/mcp-gateway-registry/blob/main/docs/aws-agent-registry-federation.md), and [peer-to-peer mesh](https://github.com/agentic-community/mcp-gateway-registry/blob/main/docs/ard.md#adding-another-registry-as-a-peer--which-mechanism). All work well when both sides are within the same trust domain (same org, same admin team, shared security posture).

### Problem

When Party A and Party B are **separate organizations**, three capabilities are needed to enable production cross-enterprise federation:

1. **A negotiation protocol.** Today an admin adds a source and records flow immediately. For cross-org use, Party B needs a way to review, accept, counter-propose, or reject a federation request from Party A before records start flowing.
2. **Bounded revocation.** If trust is broken (security incident, contract termination, compliance violation), the platform needs a way to invalidate a partner's access in bounded time (< 60s). Removing a source cleans up records on the next sync cycle, but cached tokens and in-flight calls are unaffected today.
3. **Credential lifecycle management.** Trust is configured once (add source, provide token/role) and assumed to hold indefinitely. Cross-enterprise deployments need token rotation schedules, expiry-based re-validation, and partner-scoped credential isolation for blast-radius containment.

These capabilities would extend the platform to support B2B federation where organizations have independent security teams, compliance requirements, and legal obligations.

### Why This Matters Now

- Enterprise customers in regulated industries (e.g., financial services) are asking for cross-org agent federation with audit-grade trust establishment.
- This registry already implements catalog publication, federated search, and external registry ingestion. Discovery is solved. Trust establishment is the natural next layer.

### Open Questions

1. Should the agreement be a first-class API resource in the registry, or an out-of-band artifact (e.g., signed JSON exchanged manually)?
2. What's the minimum viable agreement — is it just "scope + credentials + expiry," or does it need SLA terms and rate-limit policies baked in?
3. How should revocation propagate — push (webhook/event), pull (short TTL on tokens), or both?

### Prior Art

- OAuth 2.0 Dynamic Client Registration (RFC 7591) — programmatic credential provisioning between parties
- SAML metadata exchange — bilateral trust establishment between IdPs
- AWS Organizations SCPs — policy-based trust boundaries between accounts