[Security audit] Represent observability endpoints and data exposure in audit posture

[cssbruno]

Problem

The observability surface is not represented in the security audit posture. When tracing or the local viewer is enabled, the audit should describe the viewer, JSON, SSE, and browser-ingestion endpoints plus their access policy and data-exposure boundaries.

Evidence

• runtime/trace exposes collector JSON/SSE/browser ingestion and viewer handlers.
• Generated observability can mount trace surfaces when enabled.
• internal/securitymanifest currently records routes, endpoints, contracts, and frontend audit surfaces, but not observability-specific posture.
• Source metadata and span payloads can leave the process through viewer, SSE, JSON, console, and OTLP surfaces.

Expected Fix

Add observability posture records and baseline/declared policy hooks for trace endpoints and exported metadata.

Acceptance Criteria

• Security manifest records enabled observability endpoints: viewer, JSON data, SSE events, browser ingestion, and OTLP/export sinks where configured.
• Posture includes access policy, build mode, allowed origins, content-type requirements, body limits, batch limits, subscriber limits, source-metadata policy, and whether span data leaves the process.
• Audit output distinguishes dev-only surfaces from production-mounted surfaces.
• Baseline findings cover unsafe production exposure, missing origin/content-type checks, missing body/batch limits, and absolute source-path export.
• Tests cover observability disabled, dev-only enabled, production enabled with safe policy, production enabled with unsafe policy, and generated mount metadata.

Related: #552 tracks collector/browser-ingest hardening, #577 tracks strict collector JSON ingestion, and #583 tracks source-reference normalization.