Supervise the Prometheus exporter after startup #7284

🤖

Motivation

PR #7258 adds typed, ordered early-startup lifecycle logs and converts synchronous Prometheus build, bind, and recorder-install failures into bounded startup results. After a successful bind, the exporter future is still spawned as a detached Tokio task, matching the behavior on main. If that future later exits, the relay does not observe the terminal or initiate a controlled response.

This runtime-availability concern is intentionally separate from the metrics_bind startup phase: a post-start failure must not emit a second terminal for an already completed startup phase.

Scope

• Retain ownership of the long-running Prometheus exporter task after startup.
• Treat an unexpected exporter terminal as a bounded, secret-safe runtime failure.
• Request the relay's normal drain, await it under an independent deadline, and return a nonzero process result if the required exporter stops.
• Abort and await the exporter task during ordinary relay teardown so no task is detached.
• Preserve exactly-once startup lifecycle accounting and the existing public metrics-install compatibility API.

Required tests

• Exercise the production orchestration seam with an injected exporter future that exits after startup confirmation.
• Prove the exporter terminal is observed and reported without raw error or endpoint data.
• Prove relay shutdown is requested, owned, and bounded even if service cleanup stalls.
• Prove ordinary teardown aborts and awaits the exporter task.
• Prove metrics_bind and process_telemetry still receive exactly one startup terminal each.

References

• Logs-only startup slice: feat(relay): add early startup lifecycle logs #7258
• Original broader package: Add early process lifecycle observability #7238