(CODUX-220) Add end-to-end invocation lifecycle acceptance

[numnx]

🧩 Task: Add end-to-end invocation lifecycle acceptance

Automated task PR opened by Code UX for T07.

📋 Summary

Sprint: Sprint 220 · Reduce invocation visibility latency safely · Task: T07

Make CLI task-coding execution invocations server-visible immediately after cancellation registration and before workspace preparation, while preserving truthful provider telemetry, recovery semantics, server-authoritative dashboards, and realtime Stats freshness.

🤖 Model & Provider

Provider	Codex CLI
Model	gpt-5.6-sol

⏱️ Timing

Started	2026-07-13 18:58:17 UTC
Finished	2026-07-13 19:11:43 UTC
Duration	13m 26s

📊 Token Usage

Metric	Value
Input tokens	185,941
Cached input tokens	6,959,616
Output tokens	21,762
Total tokens	7,167,319
Invocations	1
Tool calls	65
Active time	12m 55s

Included usage estimate (subscription/local login): $5.06

✅ QA Review

⏳ QA review runs after this PR is opened. Check the task card in the dashboard for the outcome once it lands.

📝 Full Task Prompt

## Objective
Add executable fan-in coverage proving the complete CLI invocation lifecycle across persistence, preparation, provider execution, recovery/error handling, and the existing runtime-facing query surface.

## Scope
- New `tests/backend/integration/cli-invocation-lifecycle.test.ts` using the repository's in-memory/test database and deterministic deferred stages
- `tests/e2e/tasks/invocation-runtime.spec.ts`
- Existing fake `mockup-cli` runtime fixture and invocation REST query helpers

## Implementation Requirements
1. Build a deterministic backend integration harness that starts a CLI workflow with preparation held open, queries the real execution repository, and asserts one fully scoped running row with a truthful preparation message and no provider usage row before preparation/provider claim proceeds.
2. Release the workflow through provider execution and finalization, then assert exactly one execution invocation, one linked provider usage row, correct terminal fields, complete transcript, and no duplicate record after the success path.
3. Add failure and cancellation assertions showing early rows become failed or cancelled with `finishedAt` and audit text, and add resumed/recovered-provider coverage showing no second provider claim or misleading running row.
4. Extend the Playwright runtime scenario to validate the persisted invocation list and linked provider id during the normal fake-CLI run while preserving existing scope, redaction, Live snapshot, and transcript assertions.

## Constraints
- Use deterministic gates and existing mocked external boundaries; do not invoke real customer projects or live providers.
- Do not weaken timing assertions into arbitrary sleeps or lower coverage thresholds.
- Keep this task limited to executable integration/acceptance coverage; production behavior belongs in the upstream implementation tasks.

## Verification
- Run `pnpm exec vitest run tests/backend/integration/cli-invocation-lifecycle.test.ts` plus the focused backend lifecycle suites.
- Run the focused `tests/e2e/tasks/invocation-runtime.spec.ts` Playwright scenario with the repository's existing E2E command.
- Run `pnpm run build` and confirm the full acceptance flow observes early server-backed visibility, honest provider telemetry, correct cancellation/failure settlement, and no duplicate invocation records.

🌿 Branch Info

Base: feature/CODUX-220-reduce-invocation-visibility-latency-safely
Head: task/feature-codux-22-t07-codex-8b4ed5cd-mrjl52g1

---

🤖 Generated by Code UX