feat: add cueapi executions replay / verify / verification-pending

[mikemolinet]

Summary

Drains 3 entries from cueapi-cli #25's endpoints_missing:

Command	Endpoint
cueapi executions replay <id>	POST /v1/executions/{id}/replay
cueapi executions verification-pending <id>	POST /v1/executions/{id}/verification-pending
cueapi executions verify <id> [--valid | --invalid] [--reason \"...\"]	POST /v1/executions/{id}/verify

All three slot into the existing cueapi executions group — no new top-level surface, the manifest gap closes by adding subcommands.

Design notes

• verify is tri-state for valid. --valid sends True, --invalid sends False, neither sends an empty body. The empty-body path matches the server's pre-schema legacy callers (server treats absent body as valid=true). Pinned by test_executions_verify_default_omits_valid_field so a refactor can't silently start always-sending the field.

• --reason length cap (500) enforced client-side. The user gets a clean error before any HTTP round-trip. Matches the server's hard limit from VerifyRequest.

• replay carries forward payload_override. Server-side behavior (handled in replay_execution at app/routers/executions.py); the CLI surfaces the new execution_id so users can chain commands.

• Helpful 409 messages. replay 409 produces "in flight" / "in progress" copy instead of raw status code (matches server's execution_in_flight error code). verify 409 produces "cannot transition from current outcome_state."

Tests

12 new (36 → 48 total). Mock-based body capture using the same _FakeClient pattern as PR #26-#30. Pinned behaviors:

• replay POSTs empty body
• replay 409 in-flight produces helpful error
• verification-pending POSTs empty body
• verify default sends {} (no valid key)
• verify --invalid sends {valid: false, reason: \"...\"}
• verify --valid sends {valid: true}
• --reason >500 rejected client-side with clear message
• 404 surfaces "not found"
• executions --help includes the 3 new subcommands

All 48 pass locally.

No hosted-PR dependency

All 3 endpoints already shipped on prod (per app/routers/executions.py). Pure CLI catch-up.

Test plan

• python3 -m pytest tests/test_cli.py -q → 48 passed
• Manual smoke against staging:
  • cueapi executions replay <terminal-exec-id> → returns new execution_id
  • cueapi executions replay <in-flight-exec-id> → 409 with helpful copy
  • cueapi executions verification-pending <id> → outcome_state=verification_pending
  • cueapi executions verify <id> → outcome_state=verified_success
  • cueapi executions verify <id> --invalid --reason \"x\" → outcome_state=verification_failed

Parity Impact

Closes 3 entries from endpoints_missing in cueapi-cli #25's parity-manifest.json:

• POST /v1/executions/{id}/replay
• POST /v1/executions/{id}/verification-pending
• POST /v1/executions/{id}/verify

Manifest update follows after #25 merges to main.

Companion PRs

• #26 — port for hosted #589 + #590
• #27 — executions-list filter parity
• #28 — cueapi agents command group
• #29 — cueapi messages command group
• #30 — remaining create + update flags

🤖 Generated with Claude Code

[govindkavaturi-art]

Replay/verify/verification-pending commands with proper terminal-state semantics. The 409 "in-flight" handling on replay surfaces the right error message instead of dumping HTTP code. Approve.

[govindkavaturi-art]

@mikemolinet — this PR is approved but has conflict with main since #28 (cueapi agents command group) just landed. Conflict is in cueapi/cli.py (new command groups added at the end of the file collide) and tests/test_cli.py (test class definitions overlap — _AgentsClient from #28 vs your test client class).

Action: rebase onto main, keep both class definitions / both command groups.

git fetch origin main
git rebase origin/main
# In tests/test_cli.py: keep BOTH _AgentsClient AND your test class
# In cueapi/cli.py: keep BOTH the agents group from #28 AND your additions
git add -u
git rebase --continue
git push --force-with-lease

I'll re-merge as soon as it's green. Sorry for the cascade — it's the cost of merging the agents group first; the rest of your stack just needs a quick rebase. ✅