…ator

Closes the operator-value loop from PR #163. Probe runner emits
``probe.wake_requested`` → audit-log tail listener picks it up →
debounces per (probe, category) → invokes reasoning engine with
``route="probe_investigation"`` (telemetry literal activates) →
DMs operator with the investigation summary.

NO autofix execution this PR — strictly out of scope per spec.
Queued as KR-PROBE-AUTOFIX-EXECUTION.

# Surface

  * ``kora_cli/probes/wake_consumer.py`` (NEW, 340 LOC) —
    ProbeWakeConsumer singleton; per-(probe, issue_category)
    debounce table with threading.RLock; lazy reasoning + Slack
    factories matching the AlertNotifier pattern (PR #149); 3
    pure formatters (investigation prompt, operator DM, fallback).
  * ``kora_cli/listeners/probe_wake_listener.py`` (NEW, 250 LOC)
    — heartbeat-scheduler periodic task that tails the audit
    JSONL for ``probe.wake_requested`` seam rows; first tick
    stamps tail-position without replay (no historical DMs on
    boot); subsequent ticks process fresh rows in chronological
    order.
  * ``kora_cli/reasoning/engine.py`` — MessageSource Literal
    extended from 3 values to 4: added ``"probe_investigation"``.
  * ``kora_cli/reasoning/anthropic_engine.py:_derive_caller_session_id``
    — extended with the probe_investigation branch; session-id
    shape ``probe:{probe}:{category}`` so reasoning.tool_called
    rows can be joined back to the originating probe.wake_requested
    via correlation_key for future KR-REASONING-PANEL-PROBE-XREF.

# Listener wiring

Standard daemon-listener + periodic-task pattern (same shape as
heartbeat_probes_listener / alert_notifier_listener / email_inbound_imap_listener).
Imported LAST in kora_cli/listeners/__init__.py so audit reader +
reasoning engine + slack client listeners are all registered first.

# Debounce policy (v1, inline)

Per-``(probe_name, issue_category)`` map → datetime of last
dispatched. Default 10 min window via
``KORA_PROBE_DEBOUNCE_SECONDS``. Critical wakes optionally bypass
via ``KORA_PROBE_DEBOUNCE_BYPASS_CRITICAL=true`` (default false —
even critical debounces; operator opt-in). Setting
``KORA_PROBE_DEBOUNCE_SECONDS=0`` disables debouncing entirely.

Sophisticated debounce (consecutive-failure buffering, hysteresis,
backoff) queued as KR-PROBE-DEBOUNCE if v1's flat-window approach
generates false-positives in production.

# Reasoning engine context

IncomingMessage shape on probe wakes:
  * source = "probe_investigation" (the new MessageSource value)
  * text = structured investigation prompt with probe details +
    snapshot details + envelope posture
  * metadata = probe_name + issue_category + severity +
    envelope_enabled + envelope_fix_name

The engine's caller_session_id derivation produces
``probe:{probe}:{category}`` for these messages so future panel
xref can join investigations to their originating probe wakes.

# Telemetry route

The reasoning call itself bills ``route="probe_investigation"``
via the existing engine-side ``record_inference()`` call path —
PR #161's KNOWN_ROUTES already accepted the literal; this PR
activates it.

# Operator DM format

  🚨 Probe alert · fly
  {reasoning response: 2-4 sentence diagnosis + 1-line next step}

Severity emojis: critical 🚨 / warning ⚠️ / info ℹ️.

Engine failure paths produce a fallback DM with the verbatim
issue + the engine error code (engine_unavailable / cost_ladder_halted
/ engine_exception:RuntimeError / etc):

  🚨 Probe alert · fly
  fly (critical): Fly app(s) unreachable: HTTP 401

  Fly probe reported status=unhealthy. error='HTTP 401'.
  Deploy-control impact: app machines may be unreachable.

  I was unable to investigate — engine returned: engine_unavailable

# Wake-to-DM latency

  * Probe runner emits row → audit JSONL append (synchronous)
  * Listener poll cadence: ``KORA_PROBE_WAKE_POLL_SEC=30`` default
  * Worst-case wake-to-tail: ~30s
  * Reasoning + DM: depends on engine + Slack — typically sub-second once dispatched
  * **End-to-end: ~30s worst case** (acceptable for operator DMs;
    not real-time but well within "I noticed before you did" window)

Operator can tune via ``KORA_PROBE_WAKE_POLL_SEC=5`` for ~5s
latency at the cost of slightly more audit-JSONL reads per minute.

# New env vars (3)

  * ``KORA_PROBE_DEBOUNCE_SECONDS`` (default 600 = 10 min) —
    per-(probe, category) window
  * ``KORA_PROBE_DEBOUNCE_BYPASS_CRITICAL`` (default false) —
    operator opt-in to bypass debounce for critical severity
  * ``KORA_PROBE_WAKE_POLL_SEC`` (default 30) — listener tail
    cadence

  + reused: ``KORA_SLACK_JOSHUA_USER_ID`` (already in Doppler from
  PR #149's AlertNotifier wiring) — operator DM channel id.

# Pattern-discovery findings

  1. **MessageSource was a closed Literal.** Adding a 4th value
     was minimal-blast-radius (1-line Literal + 1 branch in
     _derive_caller_session_id). Spec §4 STOP-ASK #3 resolved
     inline; the engine module's source-switch shape
     accommodates new sources cleanly without further refactor.

  2. **Listener-coordinator wire is uniform across all 8 existing
     listeners.** Each listener registers via
     ``register_daemon_listener(name, factory)`` + (optionally)
     ``register_periodic_task(name, cadence, callable)``. No
     coordinator changes needed for this PR — the pattern absorbs
     new listeners cleanly. Spec §4 STOP-ASK #4 resolved inline.

  3. **Operator channel env is settled at ``KORA_SLACK_JOSHUA_USER_ID``**
     — PR #149's AlertNotifier already canonicalized this. Spec
     §4 STOP-ASK #2 resolved inline.

  4. **Tail-position stamping at first-tick** is the right
     semantic for audit-driven listeners (don't replay history at
     boot). This is the INVERSE of AlertNotifier's Q3 default
     (fire-on-first-cycle for alert-set diff) — probe wakes are
     EVENTS (timestamped), not STATE (set diff). Documented in
     listener docstring.

# Tests

42 new tests pass:
  * 26 consumer (formatters + debounce policy + bypass-critical
    env + engine error paths + slack paths + IncomingMessage
    shape + dedup state)
  * 16 listener (registration + cadence env + lifecycle + tail
    behavior: first-tick-no-replay + fresh-entry-processing +
    failure isolation + tail-advance + no-double-process)

634/634 cross-bucket regression (probes + listeners + audit +
alerts + telemetry + snapshot). Ruff clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>