Add waiting_on_operator live receipt state

[shaypal5]

Summary

Implements #82 by adding waiting_on_operator as a first-class live receipt state and non-stopped derived live session status.

What changed

• Adds waiting_on_operator to API live receipt validation, operator live status validation, and the agent schema response.
• Updates derived live session status priority:
  • operator_stop_needed remains highest priority, including the existing all-participants-settled behavior.
  • waiting_on_operator now comes before waiting_on_peer.
  • waiting_on_peer and active keep their existing fallback behavior.
• Adds D1 and Postgres migrations to widen live session/receipt check constraints.
• Updates the CLI receipt state set, help text, live-watch actionable status handling, and suggested next action copy.
• Updates the dashboard type and live-receipt docs.
• Adds focused API and CLI tests for schema exposure, receipt acceptance, derived status priority, and live-watch operator-wait handling.

Validation

• npm test - 3 files, 33 tests passed
• npm run check - passed
• npm run build - passed
• git diff --check - passed
• D1 migration replay smoke with waiting_on_operator live session status and receipt insert - passed

Milestone

No open repository milestones are currently available, so no milestone was assigned.

Closes #82

[shaypal5]

Self-review after implementation, taking the requested outsider/senior-dev stance:

1. The implementation adds waiting_on_operator in the right places: API validation, schema exposure, CLI state parsing, session-status derivation, dashboard typing, DB constraints, and tests. The derived status priority is also correct for the requested semantics: operator_stop_needed remains the hard-stop signal, while waiting_on_operator sits above waiting_on_peer as a routine operator handoff state.

Recommended action/fix: keep the state-machine behavior as implemented. Do not repurpose operator_stop_needed, and do not change the existing all-participants-settled behavior in this PR.

Applied: no code change needed for the state machine.

2. The operational docs were uneven. docs/api.md and onboarding mentioned waiting_on_operator, but the agent quickstart still only demonstrated waiting_on_peer. That is exactly where an agent would look while running a live conversation, so the new state was easy to miss.

Recommended action/fix: update the quickstart live-mode section with a concrete waiting_on_operator example and a one-line distinction from operator_stop_needed.

Applied: added the quickstart example and guidance to reserve operator_stop_needed for hard blocks/adjudication.