…t permanently brick the scheduler (tinyhumansai#3312)

A single transient cron job failure was leaving the `scheduler`
component permanently stuck in `error`, which in turn made the Docker
health check return 503 for hours until manual restart. The bug
report on tinyhumansai#3312 documents 924 consecutive health-probe failures across
7h43m of "unhealthy" container state, all triggered by a single
120-second DeepSeek API timeout on a cron agent job.

Root cause: `process_due_jobs` emits `HealthChanged { healthy: true }`
on a job success and `healthy: false` on a job failure, but only when
the queue is non-empty. The main `run()` loop emitted `healthy: false`
when the `due_jobs(...)` DB read itself failed and emitted nothing
otherwise. Once `process_due_jobs` flipped the component to `error`
on a failure, the next polls with an idle queue produced **no event
at all**, so the registry sat on the prior error forever — exactly
the state the bug captured. (In a real deployment cron queues are
empty most of the time; healthy:true emitted from `process_due_jobs`
when a job succeeds is too rare to function as a recovery signal.)

Fix: make a successful tick the recovery signal. Lift the loop body
into a `pub(crate) tick_once(config, security)` helper that emits
`HealthChanged { healthy: true }` whenever `due_jobs` returns `Ok`,
regardless of whether the resulting batch was empty. Per-job
failures inside `process_due_jobs` still flip the component back to
`error` for that tick, but the next poll that survives the DB read
re-emits the recovery signal and the registry clears. The DB-failure
branch is unchanged.

Test: `scheduler_tick_once_recovers_component_status_after_prior_error`
plants `mark_component_error("scheduler", ...)` to mimic the
post-bug-trigger state, calls `tick_once(config, security)` with an
empty job queue, waits on the bus subscriber via a short retry loop,
and asserts the registry status returns to `ok` with `last_error`
cleared. Run: `cargo test -p openhuman --lib cron::scheduler` —
51/51 pass.

Out of scope (tracked separately on tinyhumansai#3312):
- MCP server auto-reconnect (fix tinyhumansai#1 in the issue).
- Cloud → local embedding fallback on 401 session expiry (fix #2).
- More granular health probes that don't tie container liveness to a
  single component (fix tinyhumansai#4).

…inyhumansai#3312)

Two CodeRabbit follow-ups on tinyhumansai#3329.

(1) Verbose, grep-friendly diagnostics on the new `tick_once` recovery
path. Per CLAUDE.md the new flow needed stable prefixes for production
log triage, but the original commit only logged the DB-failure branch.
Added `[cron:scheduler]` traces for poll begin/ok/db_error/end with the
due-job count and an explicit "recovery signal: healthy=true" tag so the
operator can grep tinyhumansai#3312-style recovery confirmations directly out of
container logs.

(2) `scheduler_tick_once_recovers_component_status_after_prior_error`
mutated the process-global `"scheduler"` health row, and the sibling
`scheduler_flow_runs_active_hours_job_and_reschedules_inside_window`
publishes `HealthChanged` for the same component via
`process_due_jobs`. Without isolation a parallel run could flip our
entry between setup and assertion. Two-layer fix:

- `SCHEDULER_HEALTH_LOCK` (process-global `Mutex<()>`) serialises every
  test that touches the `"scheduler"` registry row.
- `SchedulerHealthGuard` snapshots the prior row on construction and
  restores it on drop, so we don't leak our error state into a sibling
  that runs after this one.

The recovery test now opens with `let _serial = lock_scheduler_health();
let _restore = SchedulerHealthGuard::capture();` — the rest of the body
is unchanged. The old `reset_scheduler_component_state` helper is gone
(the guard's restore-on-drop subsumes it).

Local: `GGML_NATIVE=OFF cargo test -p openhuman --lib cron::scheduler` —
51/51 passes, 20 consecutive runs all green.

…humansai#3312)

CI surfaced the race CodeRabbit warned about:
`scheduler_flow_runs_active_hours_job_and_reschedules_inside_window`
calls `process_due_jobs`, which publishes `HealthChanged` for the same
`"scheduler"` row that `scheduler_tick_once_recovers_component_status_after_prior_error`
asserts on. The new lock + RAII guard only worked when *both*
participants used them; the sibling didn't, so under parallel
`cargo llvm-cov` it flipped our row to `error` between
`mark_component_error` and the recovery assertion.

Acquire `lock_scheduler_health()` + `SchedulerHealthGuard::capture()`
in the sibling too. Behaviour of that test is unchanged — it just
serialises against the recovery test now.

Local stress: 20/20 consecutive `cargo test -p openhuman --lib
cron::scheduler` runs green.

…inyhumansai#3312)

The mutex + RAII guard approach from `ecca0ea1` / `1a4f60ba` was still
not enough: CI surfaced `left: "error", right: "ok"` again because
the process-global `"scheduler"` registry row is a last-writer-wins
map and **any** test in the binary that calls `publish_global(
HealthChanged { component: "scheduler", ... })` — not just sibling
tests in this module — flips it. Trying to lock every such producer
across the crate doesn't scale.

Switch the assertion to the wire instead of the row:

- Install a tokio-bus subscriber (`HealthEventCollector`) before
  calling `tick_once`.
- After the tick, wait up to 2 s for the collector to observe a
  `HealthChanged { component: "scheduler", healthy: true }` event
  published *during this test's window* (using the `before` index
  to skip whatever was already buffered).

Per-subscriber bus snapshots are monotonic and not subject to
last-writer-wins, so they don't race the registry. The fix that
production cares about — `tick_once` emitting the recovery signal on
a successful empty poll — is verified directly on the wire, and the
registry-row contract (subscriber consumes the event into the row)
is owned by `health::core` / `health::bus` tests, not by us.

This lets me delete:
- `SCHEDULER_HEALTH_LOCK` + `lock_scheduler_health`
- `SchedulerHealthGuard` + the manual restore on drop
- `wait_for_scheduler_status`
- the `lock_scheduler_health()` + guard pair I added to
  `scheduler_flow_runs_active_hours_job_and_reschedules_inside_window`
  in `1a4f60ba` — no longer needed since the recovery test doesn't
  touch the shared row.

Local stress: 51/51 in `cron::scheduler` × 20 consecutive runs all
green.

Per @oxoxDev's review nit on tinyhumansai#3329: the previous version published
`HealthChanged { healthy: true }` on every successful poll, which for
a default 30-second `scheduler_poll_secs` meant a steady event every
30s forever — bus churn for any subscriber that logs/persists/reacts
to health events, even though the registry state was unchanged.

Threaded a `&mut Option<bool> last_emitted_health` through `tick_once`
and the `run()` loop. Now publishes on **transitions only**:

- `None` → `Some(true)`: first successful tick after boot fires the
  recovery signal.
- `Some(true)` → `Some(true)`: steady-state tick, no publish (matches
  oxoxDev's "stay silent" goal).
- `Some(true) | None` → `Some(false)`: first DB failure publishes
  once; repeats stay quiet so a long outage doesn't event-storm.
- `Some(false)` → `Some(true)`: real recovery fires again.

`process_due_jobs` still emits per-job `HealthChanged` directly on
the bus, so after a job failure the local tracker is reset to `None`
to let the next surviving tick treat it as a fresh transition and
re-emit `healthy: true` — that's exactly the tinyhumansai#3312 auto-recovery
behaviour, intact.

New regression test
`scheduler_tick_once_does_not_re_emit_recovery_signal_on_steady_state`
drives `tick_once` 5 times in a row with no transition and asserts
the tracker stays at `Some(true)` (and therefore no publish ran
each tick). Asserted on the local tracker, not the global bus, to
stay race-free against the many sibling tests in this binary that
publish `HealthChanged { component: "scheduler" }` for unrelated
reasons.

Local stress: `cron::scheduler` 52/52 × 20 consecutive runs all green.