Circuit breaker for direct-delivery to long-down Mode A agents

[NeilJo-GY]

Context

Follow-up to ADR-0012 "reachable == online" (commit 5683143).

MessageRouter.route() now ALWAYS attempts the direct HTTP push for Mode A
agents regardless of the Redis alive key, with a bounded 5s connect timeout
to cap the cost of probing a down host. On failure for a believed-offline
agent it parks the message gracefully in the inbox (no DLQ, no raise).

Problem

For a Mode A agent that is genuinely down for a long time (e.g. registered
then abandoned) while senders keep messaging it, every message now pays up to a
~5s connect timeout before falling back to the inbox. The cost is bounded per
message and attempts can run concurrently, but it is still wasted work at scale.

Proposal

Add an opt-in circuit breaker so we stop probing an endpoint that has been
failing consistently:

• Track recent consecutive direct-delivery failures per agent (Redis counter
  keyed acn:agents:{id}:push_fail, short TTL window).
• When failures exceed a threshold N within the window, trust "offline" and
  route straight to the inbox without the HTTP probe.
• Any successful delivery (or touch_alive) resets the counter.
• Keep it strictly additive to the current behaviour; default thresholds tuned
  so a momentary blip never trips the breaker.

Deferred deliberately

This was deferred in the ADR-0012 work pending evidence that the short connect
timeout is insufficient. Only worth building if/when we observe meaningful
probe cost against dead Mode A agents in production.

Acceptance

• Failure-count tracking + threshold gate in route() direct path
• Reset on success / touch_alive
• Unit tests: breaker trips after N failures, resets on success, blip does
  not trip
• Configurable threshold/window (with safe defaults)

[NeilJo-GY]

Decision: observe first, breaker stays deferred.

Per the "Deferred deliberately" note, the breaker is only worth building once we
see evidence that the bounded connect-timeout probe is a meaningful cost. The
production bare-origin audit found the at-risk Mode A set is almost entirely
internal/test agents — no current evidence of a long-down real agent being
repeatedly messaged.

What was missing was a way to gather that evidence: the failure path only had
an un-aggregatable f-string log. Added structured probe-latency instrumentation
in 1e38db2 (no new state, no gating):

• direct_delivery_failed route_id=… to_agent=… believed_alive=… probe_ms=… dlq=… error=…
• direct_delivery_succeeded route_id=… to_agent=… believed_alive=… probe_ms=…

A long-down agent now surfaces as repeated direct_delivery_failed with
believed_alive=False and probe_ms near the connect timeout. Revisit this
issue (build the Redis push_fail counter + threshold gate) if/when the logs
show meaningful, concentrated probe cost. Keeping open + ready-for-agent.