feat(hook-context-intelligence): ENOSPC disk circuit breaker + user-visible fail-loud alerts (stacked on #101)

[Diego Colombo (colombod)]

Stacked on #101 — review that first

This PR is stacked on top of #101 (bkrabach — "recover from corrupt metadata.json on disk full"). Its base branch is fix/metadata-json-corruption-on-enospc, so the diff shown here is only the additive hardening layer on top of Brian's fix. When #101 merges, GitHub auto-retargets this to main.

• fix: recover from corrupt metadata.json on disk full (ENOSPC) #101 delivers the fix: atomic metadata writes (_atomic_write_text) + tolerant reads (_read_metadata) + self-heal of corrupt/empty metadata.json. Dogfooded against 4 real corrupt sessions.
• This PR delivers the resilience/UX layer fix: recover from corrupt metadata.json on disk full (ENOSPC) #101 doesn't have: a circuit breaker so a full disk stops looping, and a user-visible alert so the user actually learns data is being lost.

Related issue: microsoft-amplifier/amplifier-support#492. Follow-up design issue for the runaway events.jsonl growth that filled the disk: microsoft-amplifier/amplifier-support#493.

What this adds (and delivers to users)

1. A full disk no longer spins or spams. An ENOSPC/EDQUOT write failure opens a circuit breaker: disk writes are skipped for a capped exponential-backoff cooldown (5s → … → 300s) instead of being retried on every event; one event then probes for recovery. It never gives up and never hammers a full filesystem. This composes with fix: recover from corrupt metadata.json on disk full (ENOSPC) #101 because Brian's _atomic_write_text re-raises OSError, letting this layer classify ENOSPC.

2. Disk-full fails loud, where the user can actually see it. When the disk is full the log file can't be written either, so a logger.warning is invisible. Alerts now ride HookResult.user_message (surfaced in the UI), rate-limited, with wording matched to the real severity:

   • disk full and the event reached no destination (no server configured, or its queue is also full) → error: "PERMANENT DATA LOSS …"
   • disk full but the event was still delivered to the server → warning: local log stale, not lost.
   • recovered → one-shot info: logging resumed.

3. Events keep flowing to the server while the disk is down. Disk and network are independent sinks; the network fan-out runs regardless of disk state (enqueue is a zero-I/O in-memory hot path). enqueue() now returns whether the event was queued, so the handler can tell "delivered" from "lost" — which is exactly the distinction that decides the alert severity above.

Scope

• Additive only. Does not touch Brian's helpers or the four metadata functions; wraps them.
• logging_handler.py internal logic only — no hook wiring, config, bundle-structure, or auth changes.

Verification

• Full module suite (Brian's fix + this layer): 649 passed.
• New test_logging_handler_disk_breaker.py (10 tests): breaker opens/skips/probes/recovers, capped backoff, non-ENOSPC does not trip it, dispatch stays independent of disk, and the three alert cases — no-destination + disk full = PERMANENT DATA LOSS (error), delivered-to-server = warning, queue-also-full = permanent loss.
• ruff check / ruff format clean on changed files.

Not covered here (deliberately)

• The atomic-write/self-heal fix itself — that's fix: recover from corrupt metadata.json on disk full (ENOSPC) #101.
• Runaway multi-GB events.jsonl growth (what filled the disk) — separate design issue #493.
• Windows note: os.replace (used by fix: recover from corrupt metadata.json on disk full (ENOSPC) #101's writer) is atomic on Windows but fails if the destination is held open by another handle; nothing here holds metadata.json open across writes.

[Diego Colombo (colombod)]

Superseded by #105, which targets main directly and is independent of #101 (no duplicated code). GitHub does not allow re-basing a PR opened as part of a stack, so this one is closed in favour of the fresh independent PR. Same commit, same content.