New cockpit page + GET /api/probe-investigations endpoint that
joins three data sources per probe wake event so the operator
sees, in one place, what Kora actually did about each issue
detected by the heartbeat probes.

Joined sources
==============

  1. probe.wake_requested audit rows (PR #163 wake_emitter)
  2. reasoning.tool_called audit rows keyed by caller_session_id
     == "probe:{probe}:{category}" (PR #166 wired this
     caller_session shape via _derive_caller_session_id in
     anthropic_engine.py — pinned by drift-guard test)
  3. snapshot.service_health[probe] (current health → drives
     resolution_status: resolved / active / unknown)

Backend (kora_cli/web_server.py)
================================

GET /api/probe-investigations?window={24h|7d|all}&limit={1-200}

Returns summary counts (total / active / resolved / unknown),
current_probe_health for the 5 known probes, and per-event
items (newest first, capped by limit). Each item carries:

  * wake metadata (probe / category / severity / title / detail
    / envelope_enabled / envelope_fix_name)
  * caller_session_id (the join key, surfaced for debugging)
  * investigation: { tool_calls: [{tool_name, duration, status,
    exc_type?}], total_duration_ms, any_errored, call_count } |
    null when no reasoning rows joined (engine_unavailable etc.)
  * current_probe_health + resolution_status

Resolution semantics simplified for v1 to "currently healthy
→ resolved / currently unhealthy → active." A per-probe
observation timeline doesn't exist in the v1 substrate (only
current state), and "is this one still firing?" is the
operator's actual question.

Frontend
========

  * web/src/pages/ProbeInvestigationsPage.tsx — new top-level
    page; usePanelView("ProbeInvestigationsPage") on mount
  * api.getProbeInvestigations() + ProbeInvestigationsResponse /
    ProbeInvestigationItem / ProbeReasoningToolCall /
    ProbeResolutionStatus TS types in web/src/lib/api.ts
  * /probe-investigations route + sidebar nav entry. Placed
    after /heartbeat in the nav so the operator-flow is
    "Heartbeat (raw probe state) → Probe Investigations (what
    Kora did about an unhealthy probe)."
  * Window tabs (24h / 7d / All) reload on click
  * Per-card severity colour (critical=destructive,
    warning=yellow, info=outline) mirrors the
    wake_consumer's _SEVERITY_EMOJI mapping
  * Per-card resolution badge (Resolved=success / Active=warning
    / Unknown=outline)
  * Tool calls rendered as compact mono badges with per-call
    duration; errored calls toned warning

Empty state (spec-critical)
===========================

Per the spec — "data has only just started flowing (PR #166
merged today); render a calm 'everything's healthy' message
when zero wakes, not an empty card list." When total_count==0,
the page renders a green-toned EmptyState card with a Sparkles
glyph + "No probe wakes in the last 24 hours" headline +
reassuring copy explaining that probes haven't escalated
anything. Source-pinned by test_empty_state_message_in_page so
no one accidentally regresses it to "No data" later.

v1 deferred scope (visible via V1NotesBanner)
=============================================

Three things spec asked for that we deliberately omit, surfaced
to the operator inline so the roadmap is visible:

  * Per-call cost_usd / model_used — not durably recorded;
    aggregate per-route cost lives at /cost-telemetry under
    route=probe_investigation. Follow-on
    KR-PROBE-INVESTIGATION-COST-XREF could add per-call records.
  * DM-sent confirmation — probe DMs go through
    wake_consumer._send_operator_dm which calls
    client.post_dm() DIRECTLY, bypassing
    SlackDMHandler._append_outbound_log_entry. The outbound
    JSONL has no entry to join, so we can't truthfully say
    "DM sent at T+N" in v1. Follow-on KR-PROBE-DM-JSONL-WIRE.
  * Per-investigation summary text / model_used — the
    engine's response text is sent to Slack only, not
    recorded.

The V1NotesBanner surfaces these to the operator so the
roadmap is visible. Pinned by test_v1_notes_banner_rendered.

STOP-ASK conditions resolved inline
===================================

Per spec §4 license to simplify v1:

  * "_append_outbound_log_entry doesn't carry caller_session_id"
    → Reality is stronger: probe DMs aren't in slack_dm_log.jsonl
      AT ALL. Omitting dm_sent from response rather than
      fabricating; flagged in v1_notes for follow-on.
  * "caller_session_id pattern differs" → grepped + verified
    "probe:{probe}:{category}" matches engine literal at
    anthropic_engine.py:1289. Pinned by drift-guard test.
  * "Resolution semantics require probe-observation timeline" →
    simplified to current health (matches spec's "fine for v1"
    fallback).

Tests (tests/kora_cli/test_probe_investigations_endpoint.py)
============================================================

26 tests, all passing:

  Backend (14):
    * caller_session_id drift guard vs anthropic_engine source
    * empty audit → calm zero response
    * window=24h / 7d / all filtering
    * non-probe caller_session_ids ignored in join
    * resolution_status parametrized (5 health values)
    * wake without reasoning → investigation=null
    * wake with reasoning → investigation populated correctly
    * limit cap + clamping
    * tool_calls chronologised within investigation
    * any_errored flag + exc_type carry-through
    * SECURITY: response doesn't echo raw tool input/output
      bodies even if a future writer adds them

  FE source-pins (8):
    * api.getProbeInvestigations wrapper
    * ProbeInvestigationsResponse / Item / ToolCall types
    * Discriminated investigation field
    * Page exists + usePanelView wired
    * Route + nav entry registered
    * Empty state copy committed (regression guard)
    * V1NotesBanner rendered

Verification
============

  * 26/26 tests pass
  * tsc -b clean
  * vite build clean
  * Screenshots rendered at web/docs/probe-investigations-viewer/
    (populated.png + empty.png + preview.html sources)

Refs:
  * rafe-walker/kora-docs
    17_cc_bucket_prompts/KR-FE-PROBE-INVESTIGATION-VIEWER_wake_reason_dm_xref.md
  * PR #163 — probe.wake_requested wake_emitter
  * PR #166 — probe wake consumer + caller_session_id wiring
  * PR #159 — usePanelView instrumentation pattern
  * PR #164 — CostTelemetryPage (cross-link target for cost xref)

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