fix: capture stderr in ProcessError for better debugging (#641)

[MaxwellCalkin]

Summary

Fixes #641 — ProcessError now includes the actual CLI stderr output instead of a generic placeholder message.

Problem: When the CLI subprocess exits with a non-zero exit code, ProcessError was raised with stderr="Check stderr output for details" — a hardcoded string that provides no useful debugging information. Worse, stderr was only piped at all when the user explicitly provided a stderr callback or enabled debug mode, so in the common case the real error output was lost entirely.

Root cause in subprocess_cli.py:

1. stderr was conditionally piped (only with callback or debug mode)
2. When piped, stderr was consumed by _handle_stderr() for callbacks but never retained
3. ProcessError always used a hardcoded placeholder string

Fix:

• Always pipe stderr from the subprocess so error output is available regardless of user configuration
• Buffer all stderr lines in self._stderr_buffer (in addition to invoking existing user callbacks / debug output)
• Use the captured buffer when constructing ProcessError, so callers see the real CLI error
• Reset the buffer in close() to prevent memory leaks

Before

ProcessError: Command failed with exit code 1 (exit code: 1)
Error output: Check stderr output for details

After

ProcessError: Command failed with exit code 1 (exit code: 1)
Error output: Error: No conversation found with session ID ab2c985b

Test plan

• ruff check passes — no lint issues
• mypy passes — no type errors
• Existing test suite passes (no behavioral changes to happy path)
• Manual test: trigger a CLI error (e.g., resume non-existent session) and verify ProcessError.stderr contains the real error message

🤖 Generated with Claude Code

[c3-rambandi]

amazing, let's merge this asap

[b657bm7n98-hub]

Is this the same as #529?