feat(provider): native agy backend — rebase + continue #211

[LeoLin990405]

Context

PR #211 by @bookandlover (2026-05-21) added an initial agy provider
backend (pane-backed startup + tmux mouse defaults). Maintainer
@SeemSeam responded positively ("我考虑下新 provider") and asked for
a rebase against latest main. The PR has been idle 11+ days with no
rebase action.

I'd like to pick this up and ship it. Branch is ready and tested,
but I want to confirm direction before opening the PR.

What's in branch feat/agy-execution

Branch: https://github.com/LeoLin990405/claude_code_bridge/tree/feat/agy-execution
Compare: main...LeoLin990405:claude_code_bridge:feat/agy-execution

Rebased + cleaned onto v7.1.1 (afd61ca6):

• 4 backend files from [codex] Add AGY debugger provider and tmux mouse defaults #211 picked up clean
  (lib/provider_backends/agy/: init / launcher / manifest / session)
• Drops the mouse-default hunks (already merged via Allow CCB_KEYCHAIN_SERVICE_OVERRIDE to bind agent materialization to a specific keychain entry #212)
• Re-registers agy in runtime_shared.py +
  registry_runtime/builtin_backends.py (OPTIONAL_PROVIDER_NAMES)
• 12 tests pass (catalog, registry maps, env override,
  yolo-permission default, continue-for-restore)
• README + README_zh updated to list agy in supported providers

$ uvx --with pyyaml --with tomli pytest \
    test/test_v2_provider_catalog.py \
    test/test_v2_provider_core_registry.py \
    test/test_v2_runtime_launch.py::test_provider_start_parts_respect_env_override \
    test/test_v2_runtime_launch.py::test_provider_start_parts_fall_back_to_default_binary \
    test/test_v2_runtime_launch.py::test_agy_start_cmd_defaults_to_yolo_permission \
    test/test_v2_runtime_launch.py::test_agy_start_cmd_uses_continue_for_restore -q
# 12 passed in 0.12s

Use case (why agy as a first-class provider)

Multi-agent fan-out workflows that mix Codex / Claude / Anthropic-
compatible CC 分身 / Antigravity benefit from having agy as a
first-class CCB agent rather than running it as a cmd shell pane.
v7 multi-window topology rejects cmd provider, so the only current
way to use agy inside CCB is out-of-band (agy -p "..." from a
separate terminal), which loses sidebar visibility and the
/ask collaboration channel for it.

After this lands, debugger:agy(worktree) and cc-agy:agy(worktree)
become valid topologies in .ccb/ccb.config.

Intentional limitation (follow-up planned)

execution_adapter=None — same scope as #211. ccb ask cc-agy "..."
routing requires a full execution adapter (mirroring
codex/execution.py + execution_runtime + comm.py log reader),
which I'll land in a separate follow-up PR after this one merges, to
keep the diff reviewable.

Questions for maintainer

1. OK to open the PR from this branch (pane-backed only, follow-up
   for adapter), or would you prefer a different shape?
2. Credit line for @bookandlover acceptable in PR description and
   commit messages?
3. Naming: PR uses agy (matches CLI binary). Anything you'd want
   different (e.g. antigravity as the manifest name)?

Happy to open the PR immediately if direction is OK. Also willing to
coordinate with @bookandlover if they're still around.

cc @SeemSeam @bookandlover

[LeoLin990405]

Closing this proposal. After investigation, Google Antigravity (agy) exposes no headless/remote API — the agy CLI is OAuth-only, the app has no API, and the IDE CLI has no agent flag — so a native agy provider backend isn't viable for the bridge's headless model. #211's groundwork stays useful if agy ever ships a headless surface. Thanks @bookandlover @SeemSeam.