stream-json / text modes return assistant_output_timeout against claude 2.1+ (marker character changed)

[sahrizvi]

Summary

claude-p 0.1.4 against claude 2.1.19 (latest installed via claude install)
consistently returns claude-p error: assistant_output_timeout even though
the underlying TUI produced a valid assistant response. Reproduces in all
three --output-format modes (text, json, stream-json) and is independent
of subscription vs API auth.

Cause

claude 2.1+ changed the leading bullet on assistant messages from
U+23FA (⏺, BLACK CIRCLE FOR RECORD) to U+25CF (●, BLACK CIRCLE).
extract_assistant_snapshot is hardcoded to rfind("⏺"), so on
post-2.1 claude it never finds a marker, returns an empty string,
and classify_failure flags the run as assistant_output_timeout.

Evidence

Captured TUI raw log via --raw-log /tmp/diag.raw.log while running:

claude-p 'Respond exactly: DIAG_OK' --tools '' --timeout-sec 60 \
  --quiet-after-sec 30 --model claude-haiku-4-5 --output-format text \
  --raw-log /tmp/diag.raw.log

Wrapper printed claude-p error: assistant_output_timeout, but the raw
log contains the actual assistant response right after a ● bullet:

●DIAG_OK
● DIAG_OK

Byte counts in the raw log confirm only the new marker is emitted:

U+23FA (⏺) count: 0
U+25CF (●) count: 2
DIAG_OK count:    4

Source point: src/claude_p/cli.py lines 154-160 (extract_assistant_snapshot).

Environment

• claude-p: 0.1.4 (PyPI)
• claude CLI: 2.1.19 (installed via claude install)
• OS: Linux (also reproduced in non-interactive sandbox shells)
• Python: 3.14

Suggested fix

Recognize both markers (forward-compatible: if a future claude version
flips again, both codepoints stay supported). PR incoming.