feat: add fire + executions subgroup (parity with @cueapi/mcp 0.4.0)

[mikemolinet]

Summary

Brings cueapi-cli to parity with the @cueapi/mcp 0.3.0 + 0.4.0 surface for fire-cue and worker-execution-lifecycle operations. Replaces the curl invocations agent users have been falling back to for these operations.

What's added

One top-level command:

Command	Wraps	Notes
cueapi fire <cue-id> [--payload-override JSON] [--merge-strategy merge|replace]	POST /v1/cues/{id}/fire	Ad-hoc one-shot triggers; using cues as a messaging channel between agents.

One new subgroup with seven commands:

Command	Wraps	Notes
cueapi executions list	GET /v1/executions	Historical executions across all cues.
cueapi executions list-claimable [--task] [--agent]	GET /v1/executions/claimable?task=&agent=	Server-side SQL filter (NOT client-side).
cueapi executions get <id>	GET /v1/executions/{id}	Single-row fetch.
cueapi executions claim <id> --worker-id ID	POST /v1/executions/{id}/claim	Atomic; returns 409 if already claimed.
cueapi executions claim-next --worker-id ID [--task]	POST /v1/executions/claim (no task) OR list+claim chain (with task)	Internal fan-out when --task is set.
cueapi executions heartbeat <id> --worker-id ID	POST /v1/executions/{id}/heartbeat with X-Worker-Id header	--worker-id REQUIRED at the CLI even though server permits omission.
cueapi executions report-outcome <id> --success/--failure [--external-id ...]	POST /v1/executions/{id}/outcome	Write-once; outcome immutable.

Notable design choices

• list-claimable filter is server-side, not client-side. Client-side filter after fetch hits the LIMIT 50 starvation bug that was fixed in the 2026-04-25 prod incident (see app/routers/executions.py:122-131 docstring in cueapi-core for the prior repro). Same call we made on @cueapi/mcp 0.4.0 PR chore: add CONTRIBUTING.md #11.
• claim-next --task fans out via list-claimable + claim by ID because the server's POST /v1/executions/claim endpoint does not accept a task filter today. Tiny race window between list and claim is bounded by the atomic claim returning 409, in which case the caller retries.
• heartbeat sends worker_id via the X-Worker-Id request header, not body. That is the server's actual transport for the field (declared Header(None) at app/routers/executions.py:317). --worker-id is required at the CLI even though the server permits omission, so misconfigured callers fail at the CLI instead of silently bypassing the race-protection check at the server.

Tests

pytest tests/ 36 pass (was 19, +17 new). All new tests follow the existing CliRunner help-text + arg-parsing pattern. No live API calls.

36 passed in 0.05s

Version

0.1.5 -> 0.2.0. Minor bump for additive new feature surface.

Also aligned cueapi/__init__.py (had drifted to 0.1.3) with pyproject.toml while bumping; both now at 0.2.0.

Out of scope

• Tab-completion / shell-completion hooks for the new subcommands.
• Pretty-printing for execution outcome metadata beyond status / external-id / result-url / summary.
• Action repo update (cueapi-action) to expose the new commands; that's a separate PR queued behind this one shipping to PyPI.

Lineage

• Wrappers parity work captured in PRD (PM-coordinated; not public).
• @cueapi/mcp 0.3.0 (cueapi_fire_cue) and @cueapi/mcp 0.4.0 (the five execution-lifecycle tools) are the upstream pattern this PR mirrors.

[mikemolinet]

Superseded by upstream-branch PR (will be opened next). Fork-PR can't access staging secrets needed by integration tests.