feat(api): apply participant session commands over HTTP

[cursor]

Why

A purchaser can create a session (#149) and can post responses only after the session is already Active (#195). Protected main has the domain command machine, but TRD POST /v1/sessions/{session_ref}/commands was still Target. Without Activate/Complete over HTTP, the assessment loop cannot start or freeze answers.

This slice is intentionally not on the #98 published-release load stack. Prefer #180 for locked start-from-store. Prefer #177 for recovery claim_deadline_at.

What this PR does

• In-process POST /v1/sessions/{session_ref}/commands applies Activate, Pause, Resume, Complete, or Cancel.
• Exact Idempotency-Key replay returns the original resulting state and sequence without minting a new command.
• Scoring and operator commands (begin_scoring, record_score, release, expire, invalidate) fail closed and tell the caller to stay on this participant family until Complete.
• Illegal transitions tell the next legal action (activate first, resume before Complete, start a new session after cancel).
• As-built OpenAPI 3.2.0 is limited to this one operation (openapi/session-commands.yaml).
• RFC 9457 problem details; no raw request/SQL/provider echo (Nottingham, Wilde, & Dalal, 2023).

Out of scope

• Session create/reload HTTP (feat(api): create and reload in-process sessions over HTTP #149)
• Response HTTP (feat(api): record active-session responses over HTTP #195)
• Item-delivery HTTP (feat(api): record and reload item deliveries over HTTP #197)
• Locked stored-release start (feat(session): start sessions from locked stored publication state #180)
• Command-history PostgreSQL persist
• Live scoring or result HTTP

Test plan

• cargo test --test session_command_http_contract --test session_command_http_listener_contract --test session_state --test session_aggregate_lifecycle --test documentation_architecture_contract --test traceability_active_pr_contract
• cargo clippy --all-targets -- -D warnings
• cargo fmt --all -- --check

Operator next action

After exact-head Runtime CI and an independent last-push review, bind 0.0.0.0:$PORT and POST {"command":"activate"} with an opaque Idempotency-Key. Then POST /v1/sessions/{session_ref}/responses for each published item. After the last answer, {"command":"complete"}.

Do not merge until exact-head checks and independent last-push approval are satisfied. Never self-approve.