fix(hook-context-intelligence): forwarding-path reliability & diagnostics hardening

[Diego Colombo (colombod)]

What this changes

Four independent reliability/diagnosability fixes to hook-context-intelligence's
server-forwarding path, plus a small test-import lint fix. Each is an atomic commit;
none changes the on-disk event format or the guarantee that events are written durably
to events.jsonl before any dispatch is attempted.

1. Retry HTTP 408 instead of dropping the event

_classify_http_outcome treated 408 (Request Timeout) as permanent, so a timed-out POST
was skipped rather than retried. 408 is transient by definition (RFC 7231 permits
repeating the request unchanged); it now retries with backoff like 429/5xx. Other codes
are unchanged.

2. Make auth-token failures diagnosable

When producing the Authorization header failed, the only durable record was a constant
string — every distinct cause (expired token, wrong audience, broker unavailable, a
masked bug) produced the same uninformative line, and a burst collapsed to one. The
durable forwarding record now carries the exception type + message and is written
per-failure (moved out of the console rate-limit branch); console logs stay rate-limited.

3. Positive liveness heartbeat

The diagnostics sink only ever wrote on a problem, so an empty log was ambiguous between
"healthy", "never started", and "no sessions ran". A destination now writes one
delivery_ok record on its first successful delivery per session. An empty log now means
something specific.

4. Fault-isolate per-destination dispatcher construction — completes #85

on_session_ready built all dispatchers in a bare comprehension. If constructing one
destination's dispatcher raised (e.g. the azure-identity credential chain failing to
initialise for an entra destination — an environmental failure that config validation
cannot screen), the exception propagated out of on_session_ready; the kernel swallows
it, so set_dispatchers() and event registration never ran. One misconfigured
destination silently disabled forwarding for every destination, including healthy ones,
with no diagnostic anywhere.

Each construction is now isolated in its own try/except: the failing destination is
skipped, the rest still forward, and the failure is recorded durably in the
forwarding-diagnostics JSONL (dispatcher_construction_failed, carrying the exception
type + message) as well as the kernel log.

This completes PR #85. #85 made validate_destinations() degrade per-destination at
the config-validation layer so a misconfigured destination can't take down local capture.
This applies the same per-destination isolation one layer deeper — at dispatcher
construction — which #85 left unguarded, and routes the diagnostic into the same
forwarding-diagnostics JSONL as the source of truth.

End-user impact

• Transient server timeouts no longer silently drop events out of the live graph.
• Auth problems are diagnosable from the durable forwarding log alone — no need to have
  had DEBUG enabled before the fault occurred.
• An empty forwarding log is now unambiguous: a heartbeat proves the destination was live.
• A single bad destination can no longer silently disable forwarding for every other
  destination — and when one is dropped, it says so, durably, where operators look.

Validation

• Unit: full module suite green (636 passed); ruff, ruff format, and pyright all clean.
• End-to-end in isolated Digital-Twin environments (isolated Neo4j + context-intelligence
  server), each fix proven against a pre-fix control:
  • 408: fixed retries to delivery ([408,408,408,202]); pre-fix control loses the event (permanent_reject, 3 events dropped).
  • auth: durable record carries ClientAuthenticationError: …; 5 distinct faults → 5 distinct records.
  • heartbeat: exactly one delivery_ok per session over 23 delivered events.
  • construction: fixed emits dispatcher_construction_failed for the bad destination and the healthy destination still forwards (Neo4j node count confirmed); pre-fix control loses ALL forwarding silently.

[Diego Colombo (colombod)]

What this improves for end users

Context Intelligence forwards each session's events to a shared graph server so the team's graph stays current. These fixes make that forwarding more reliable and, when something does go wrong, actually diagnosable — without changing how events are captured locally (they remain durably written to events.jsonl before any network call).

After this PR:

• Fewer stale-graph gaps from transient timeouts. A server that momentarily times out a request (HTTP 408) used to make the bundle drop that event from live delivery. It now retries it, so the event reaches the graph on a later attempt instead of only via a manual re-upload.
• Auth problems you can actually diagnose. When the bundle can't mint an auth token, the durable forwarding log used to record the same opaque line for every possible cause. It now records the actual exception type and message — so an expired login, a wrong audience, or a broker outage are told apart from the log alone, even if DEBUG wasn't enabled before the fault.
• An empty log that means something. A healthy destination used to write nothing, so "no records" was ambiguous between "working fine", "never ran", and "silently broken". A destination now writes one delivery_ok heartbeat per session, so silence is unambiguous.
• One bad destination can't silently take down the rest. If a single destination's credentials failed to initialise, the bundle previously aborted setup for every destination (including healthy ones) and left no diagnostic where anyone would look. Now the bad destination is skipped, every other destination keeps forwarding, and the failure is recorded durably in the forwarding log (dispatcher_construction_failed). This completes fix: misconfigured remote destination must not disable local capture #85, which handled the same "one bad destination shouldn't break the others" principle at the config-validation layer — this PR extends it to dispatcher construction.

Net effect: the team graph stays fresher, and when forwarding does degrade, the durable forwarding log now tells you what failed and which destination — instead of going quiet.