Replace the worktrunk-marker convention with CAP (cap-protocol.org) once it stabilizes

Depends on #86.

Problem

The marker convention proposed in #86 is worktrunk's own bespoke git-config
format, populated only by the specific plugins worktrunk ships for Claude
Code, Codex, OpenCode and Gemini CLI
(https://worktrunk.dev/claude-code/#activity-tracking) — any other agent CLI,
or a user who hasn't installed the matching plugin, gets nothing, and
git-wipe falls all the way back to #66's coarse process scan.

CAP is a draft protocol (v1, public review since
2026-05-18) purpose-built for the same problem from the orchestrator side:
driving/observing any CLI agent uniformly. Its agent manifest already models
the "working vs waiting" distinction generically, without per-agent plugins:

[parse]
idle = ["^> $", "^❯ $"]

An agent's manifest declares its idle-state pattern once; a CAP-aware consumer
matches it against the agent's PTY output (or a structured fast-path event,
when the agent exposes stream-json/gRPC/ACP/A2A) to know whether it's idle
or mid-turn — a superset of worktrunk's binary 🤖/💬 marker, sourced from the
agent/protocol layer instead of a third-party tool's plugins.

Proposal

This is explicitly not actionable yet. CAP is a draft spec with a
reference implementation "in progress" and no released agent manifests, per
its own roadmap (stated bar for wider governance: "once 3+ independent
implementations exist"). Filing this now so it isn't forgotten; revisit once:

• CAP publishes a stable (non-draft) Core v1 spec, and
• either a released crate implementing the manifest/PTY-parsing side exists to
  depend on, or the manifest format is stable enough to parse [parse].idle
  directly, and
• first-party manifests exist for the agents actually used against this
  project's worktrees (Claude Code, Codex, OpenCode, Gemini CLI, aider, ...).

When those conditions hold, extend the detection added in #86 with a second,
preferred source: look for a CAP manifest for the running agent (bundled with
the agent, /usr/share/cap-agents/, or via --cap-manifest) and derive
working/waiting from its [parse].idle pattern rather than — or in addition
to — the worktrunk git-config marker. Keep the worktrunk-marker path as a
fallback for repos without CAP-aware agents rather than removing it; the two
are not mutually exclusive.

Acceptance

• Stays open/blocked and out of scope for implementation until CAP Core v1
  leaves draft status.
• When picked up: CAP-sourced status takes priority over the worktrunk
  marker when both are available; the worktrunk marker remains the
  fallback for non-CAP agents.
• No new required runtime dependency on an unstable/pre-1.0 crate — vendor
  or gate behind a feature flag if the reference implementation is still
  pre-release at that time.

Start by reviewing issue #86 and CAP Core v1 status before considering implementation; this issue is explicitly blocked while CAP remains a draft. When the stated stability, implementation, and manifest conditions are met, verify that CAP-derived status takes priority, the worktrunk marker remains a fallback, and no unstable runtime dependency is required.