fix: detect Claude in Chrome permission prompts as waiting_input

[kbwo]

Problem

Claude Code shows browser-extension permission prompts (e.g. "Claude in Chrome wants to create a browser window and read your tabs") as a numbered Allow/Deny menu:

 Claude in Chrome wants to navigate on example.com

 https://example.com/app

 ❯ 1. Allow
   2. Allow all actions on example.com for this session
   3. Deny (esc)

These prompts contain none of the markers the Claude state detector currently keys on — no "Do you want" / "Would you like" phrasing and no "esc to cancel" footer — so ccmanager reports the session as idle while it is actually blocked waiting for the user to answer. The user gets no waiting-input indication (status icon, notification hooks) for these prompts.

The fix detects the numbered N. Deny (esc) option line, which is present in both the 2-option (Allow / Deny) and 3-option (Allow / Allow all actions / Deny) variants, and classifies it as waiting_input. The "wants to ..." sentence itself is deliberately not used as a marker because that phrase commonly appears in ordinary assistant prose and would cause false positives.

Verification

Prerequisites:

• bun install from repo root.

Steps:

• bun run test src/services/stateDetector/claude.test.ts — 77 tests pass, including two new cases that reproduce the 2-option and 3-option permission prompts verbatim and assert waiting_input.
• bun run lint, bun run typecheck, and full bun run test (1790 passed / 10 skipped) succeed on the branch.
• Manual check: inside a ccmanager session, trigger a Claude in Chrome permission prompt (e.g. ask Claude Code to open a page with the Chrome extension enabled) and confirm the session status changes to the waiting-input state instead of idle while the Allow/Deny menu is displayed.

🤖 Generated with Claude Code