Re-land PR #372 (logger.status() bridge) in phases, extended with audience + remediation

## Summary

PR #372 (logger `.status()` API bridging log calls into the ComponentStatusRegistry, plus system health checks and a hierarchical `get_status` view) is the right foundation for status-first monitoring: problems become durable, queryable, alertable *state* with explicit resolution, instead of inferences over log text. The PR is from April and now stale (merge conflicts, CI red, and the status registry has evolved on main), so re-land it in phases rather than rebasing wholesale.

## Design extensions on top of the original #372 design

1. **`audience: operator | user`** on status entries and the `.status()` call (see the audience issue) — operator vs customer responsibility split from day one.
2. **`remediation` field** — a short action string and, where applicable, a machine-usable hint (operation name like `repair_blob_data`, config key, or doc link). Statuses become actionable: `get_status` tells you what's wrong *and* what to do; Studio can render a "fix" affordance; Harper Eye gets structured input instead of log archaeology.
3. **`occurrenceCount` + first/last-seen** (already in the #372 design) — the status entry absorbs repetition, complementing log dedup (harper-pro#262).

## Phasing

- **Phase 1:** logger `.status({problem|resolves, expires, audience, remediation})` bridge + registry field extensions. Convert the highest-value call sites, priority ordered by the 2026-07-06 Datadog audit: replication connection/auth path (top noise + real incidents), blob receive/pending paths (multiple silent-divergence incidents: harper-pro#386, #426, #502), MQTT auth, storage reclamation.
- **Phase 2:** lifecycle (expiry timers, source tracking, occurrence counting) hardened in the registry.
- **Phase 3:** hierarchical rollup in `get_status` (worst-of-children), consumed by Studio/central-manager.
- **Phase 4:** system health checks (disk/memory/CPU thresholds, self-healing statuses) — config-gated.

## Related
PR #372 (original design + code), harper-pro#437, audience issue, auth-flap issue (first Phase-1 conversion target).

🤖 Filed by Claude on behalf of Kris.

Start by reading PR #372 and the logger.status() bridge design, then compare its registry changes with the current status registry on main. Trace the Phase 1 call sites listed in the issue, beginning with the replication connection/auth path, and use the stated phases as the completion boundary for each incremental change.

Written by the indexing model from the issue text.