Expose process-signal bridge status and registration lifetime

[autocarl]

Context

The process-signal coordinators introduced by PR #80 install lazy process-lifetime callbacks and keep them inert when no automatic run is active. This avoids callback-snapshot teardown races and does not retain a ReplApp, but a long-lived embedding host cannot currently inspect:

• whether the bridge is supported on the current platform;
• whether registration succeeded or automatic handling degraded to caller-owned handling;
• whether an ownership epoch is active or draining;
• why process-global callbacks remain installed after a run.

PR #80 adds diagnostics for unsupported platforms, registration failures, ignored external-host options, and callback failures. A later API can make the effective state auditable without exposing mutable global internals.

Acceptance criteria

• Applications can query the effective signal-handling mode and platform support.
• Registration lifetime and inert-state guarantees are documented in a public contract.
• Observability does not let consumers corrupt the process-wide epoch.
• Long-lived embedded-host scenarios are covered.
• Evaluate whether registrations should remain process-lifetime or be represented by an auditable lease without reintroducing teardown races.