Add Fizzy/Codex work item orchestration support

[joshyorko]

Goal

Augment robocorp_adapters_custom so it can serve as the durable execution queue for Fizzy-backed Codex orchestration.

Current fizzy-symphony should not rebuild queue leasing, retries, orphan recovery, or multi-worker state. The workitems adapters already provide the right primitives. We should add a small integration layer that lets Fizzy cards become Robocorp work items and lets Codex workers report results back to Fizzy.

Proposed shape

1. Work item payload contract

Define a stable payload schema for coding-card work items:

{
  "source": "fizzy",
  "card": {
    "id": "03...",
    "number": 579,
    "title": "Implement feature",
    "description": "...",
    "url": "https://...",
    "board_id": "...",
    "column_id": "...",
    "state": "Ready for Agents",
    "labels": [],
    "branch_name": "..."
  },
  "workflow": {
    "prompt_template": "...",
    "allowed_paths": ["src/", "tests/", "docs/"],
    "handoff_column": "Synthesize & Verify"
  },
  "runner": {
    "kind": "codex",
    "command": "codex exec --json"
  }
}

2. Producer helper

Add helper/API or example task that:

• calls local fizzy card list --board BOARD --agent --json or --quiet
• normalizes cards into work item payloads
• enqueues them via workitems.outputs.create(...) or adapter seed_input(...) for local/dev
• avoids duplicate queue entries for the same Fizzy card number unless explicitly forced

3. Worker helper

Add RCC/Robocorp task example that:

• reserves one work item
• creates/reuses a per-card workspace
• runs codex exec or configured Codex command
• attaches stdout/stderr/proof artifacts to the work item
• marks item.done() on success
• marks item.fail(exception_type="APPLICATION", ...) on technical failure
• preserves enough payload/result data for a reporter to update Fizzy

4. Reporter helper

Add task/helper that consumes completed worker outputs and:

• posts proof via fizzy comment create --card NUMBER --body BODY --agent --quiet
• moves card via fizzy card column NUMBER --column COLUMN_ID --agent --quiet
• optionally closes/postpones via fizzy card close / fizzy card postpone

5. Adapter/backend requirements

Make sure existing adapters support this orchestration pattern:

• idempotency key or duplicate detection for card-number payloads
• explicit queue names for clean producer -> worker -> reporter stages
• recover orphaned/reserved items reliably
• optional metadata query helper for queue depth / state counts
• file attachment support for logs/artifacts across SQLite, Redis, DocumentDB, Yorko Control Room

Why this belongs here

robocorp_adapters_custom already has the hard parts:

• pluggable storage backends
• PENDING -> RESERVED -> COMPLETED/FAILED
• SQLite WAL/local dev path
• Redis/DocumentDB/Yorko distributed paths
• orphan recovery
• RCC-compatible task examples

Fizzy should stay the board/source of truth. Workitems should be the durable execution queue. Codex should be the worker runtime.

Acceptance criteria

• Add docs describing Fizzy-card work item schema and 3-stage producer/worker/reporter flow.
• Add at least one SQLite-backed local example using RCC.
• Add tests for duplicate prevention/idempotency if implemented.
• Add tests or documented validation for completed/failed worker result propagation.
• Do not require direct Fizzy HTTP access; use the local fizzy CLI contract.
• Do not bake Codex-specific logic into adapters; keep runner command configurable.

Related context

This issue comes from fizzy-symphony exploration. We decided not to duplicate durable queue/orchestration mechanics there when Robocorp workitems already provide the correct primitive model.