test: isolate the prompt_toolkit app session so UI tests run on Windows

[MohammedAlkindi]

Summary

On Windows, 62 occurrences of prompt_toolkit.output.win32.NoConsoleScreenBufferError take out 31 tests in tests/unit — the suite your checks.yml runs as uv run pytest tests/unit -v.

Building a prompt_toolkit Application binds the ambient AppSession's output, and constructing that output probes the terminal for its screen buffer. Under pytest's captured stdout that probe fails on Windows:

prompt_toolkit/output/win32.py:220: in get_win32_screen_buffer_info
    raise NoConsoleScreenBufferError
E   prompt_toolkit.output.win32.NoConsoleScreenBufferError: Found xterm-256color,
    while expecting a Windows console.

Linux CI never sees this, because the POSIX Vt100_Output has no equivalent probe — the failure needs a Windows host and a non-console stdout, which is exactly the pair CI cannot produce.

Changes

One autouse fixture in tests/conftest.py, alongside the existing isolate_herdr_lifecycle, binding a DummyOutput and a pipe input for the duration of each test. This is the documented prompt_toolkit pattern for testing, and it makes the session explicit rather than ambient — which also stops the tests reaching for the real terminal when run locally.

Testing

Windows 11 (10.0.26200), Python 3.12.10, clean clone of main at 0b8a364, pip install -e . plus pytest/pytest-asyncio.

pytest tests/unit	before	after
failed	231	200
passed	7157	7188
skipped	20	20
NoConsoleScreenBufferError occurrences	62	0

Totals reconcile at 7408 collected either way, and failures fell by exactly the number passes rose (31), so no previously-passing test changes state on Windows.

What is deliberately unchanged

This fixes one cause, not the Windows run as a whole — 200 failures remain and I have not touched them. From a quick triage they are mostly separate concerns: tests asserting POSIX path strings (tests/unit/fast_agent/utils/test_path_display.py expects src/app.py where Windows correctly produces src\app.py), a uvloop fallback test, and docs-snapshot comparisons. Several look like test-side platform assumptions rather than product bugs, and some may be intentional. I did not want to bundle judgement calls about those into a change that is mechanically verifiable on its own.

Limits I want to be upfront about

I could not run this on Linux, so I have not verified there. The change is test-only and DummyOutput is prompt_toolkit's own testing primitive, but a global autouse fixture does alter the ambient session for every test — if any Linux-only test depends on the real output object, CI will surface it and I will happily scope the fixture down to the UI packages instead. Your CI is the authority here, not my run.

Note on AI assistance

I used an AI assistant while working on this. The before/after suite runs, the failure-cause counts, and the reconciliation of the totals quoted above were all executed by me on the Windows machine described, and I confirmed the specific traceback in win32.py:220 rather than inferring the cause from the test names.