feat(observability): define gateway-to-exporter extension contract

No se nombran archivos de implementación, pruebas ni puntos de entrada. Empieza revisando la documentación de arquitectura y los issues relacionados #1055, #2745 y #2762; terminado significa contar con un contrato gateway-to-exporter acordado y documentado que cubra registros, brechas, aislamiento, instalación, configuración y comprobaciones de salud.

User Story

As an OpenShell operator, I want a simple, supported way to send observability data to my existing tools without assembling separate collectors.

Problem Statement

The observability work under #1055 needs a shared boundary between OpenShell producing authoritative records and an exporter processing them for customer destinations.

Impact / Why This Matters

Destination-specific formats, credentials, storage, queues, and retries add work and dependencies to the gateway. An external exporter can handle that work and scale independently. The gateway still carries collection and relay costs.

Proposed Design

Supervisor → Gateway → External exporter → Customer tools

• Supervisor: emit structured signals and source-health information through its existing authenticated gateway connection. No additional exporter connection or heavy export processing.
• Gateway: expose an authenticated, read-only, scoped source that preserves native records, authoritative identity and context, and reports known gaps and recovery limits. Keep telemetry resource use bounded.
• Exporter: handle destination-specific transformations, additional redaction, buffering, retries, and delivery outside the gateway.

Make this a first-class integration with one documented installation, configuration, and health-check workflow. Operators should not need to assemble multiple collectors.

Operational delivery and optional evidence processing can be functions within the same exporter deployment. Ordinary observability must not require evidence infrastructure; detailed evidence behavior remains in #2745.

This proposal defines the shared integration boundary for work such as #2762. Transport and storage choices remain open.

Acceptance Criteria

• Structured records reach a configured destination without parsing human-readable shorthand.
• Recovery limits and known gaps are visible.
• Slow exporters or destinations do not block gateway control operations or sandbox enforcement.
• Installation, configuration, and health checks follow one supported workflow.

Alternatives Considered

Gateway-owned destination integrations reduce deployment components but expand gateway responsibilities. Independent collectors leave operators assembling the integration themselves.

Checklist

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request