fix: keep the startup banners from crashing on a non-UTF-8 stdout - #3050

…out (#3056)

* fix: keep result lines from crashing on a non-UTF-8 stdout

#3050 stopped the startup banners from raising UnicodeEncodeError on a
Windows console, but the banner was not the only line the ANSI codepage can
break. Two ordinary things a run prints still went through a bare print():

- the --enrich notifications built in checking.py carry U+2192, which cp1252
  has no slot for (checking.py:1847, 1851, 1859, 1899);
- any profile field maigret extracts carries the script the page was written
  in, so a Cyrillic or CJK fullname breaks the result line that reports it.

Both arrive mid-scan, after the network work is done, so the crash discarded
results the run had already collected -- worse than failing at startup.

Route every write in notify.py through the existing _print_encodable helper.

Verified on a real cp1252 stdout, not a mock: both cases raise before this
change and print with replacement characters after it.

* fix: keep the AI spinner alive on a stderr that cannot encode braille

Second half of #3055. The spinner frames are braille, which cp1252 -- the
ANSI codepage of a stock Windows install -- cannot encode, so the first frame
raised UnicodeEncodeError inside the daemon thread: the thread died with a
traceback printed over the output and the animation stopped for the rest of
the run.

Encoding with replacement would only leave a row of '?' spinning, so pick the
frame set from what the stream can carry instead. A UTF-8 terminal keeps the
braille; anything that cannot hold it gets |/-\ and still animates.

print_streaming() in the same module writes model output the same way and
would raise on any non-Latin reply, but it has no callers anywhere in the
tree, so it is left alone rather than fixed as dead code.

Third of the same shape as soxoj#3050 (startup banners) and soxoj#3056 (result
lines and the spinner). The one terminal write in the AI module that was
not covered is the analysis itself.

_stream_response() writes each token of the model's reply straight to
stdout. The reply is arbitrary text, and an OSINT run on an international
username routinely comes back with Cyrillic or CJK. On Windows, Python
takes stdout's encoding from the process ANSI codepage -- cp1252 on a
default install -- so that write raises UnicodeEncodeError, the exception
leaves the coroutine, and the analysis ends mid-sentence with the tokens
already printed left on screen.

sys.stdout's error handler is surrogateescape, which is not a guard here:
it rescues lone surrogates only, so an ordinary unencodable character
still raises. There is a test that pins exactly that, so this suite
notices if the platform ever changes.

Also corrects the _frames_for docstring, which I wrote in soxoj#3056. It says
the braille frames "raised UnicodeEncodeError inside the spinner's daemon
thread". They did not: unlike stdout, stderr's error handler is
backslashreplace, so the write never raised -- it printed the escape, and
the animation became a column of literal ⠋. The fix was right, the
reason given for it was not, and the difference between the two streams
is exactly what this change turns on.

print_streaming() writes to stdout the same way and has the same defect,
but it has no callers anywhere in the tree, so it is left alone rather
than changed without a way to exercise it.

Verified: 6 tests added to tests/test_ai.py, driven by real cp1252 streams
rather than mocks so the codec decides. Three mutations, all killed.
Full suite on Windows: the set of failing test names is identical before
and after (35 pre-existing).

Third of the same shape as #3050 (startup banners) and #3056 (result
lines and the spinner). The one terminal write in the AI module that was
not covered is the analysis itself.

_stream_response() writes each token of the model's reply straight to
stdout. The reply is arbitrary text, and an OSINT run on an international
username routinely comes back with Cyrillic or CJK. On Windows, Python
takes stdout's encoding from the process ANSI codepage -- cp1252 on a
default install -- so that write raises UnicodeEncodeError, the exception
leaves the coroutine, and the analysis ends mid-sentence with the tokens
already printed left on screen.

sys.stdout's error handler is surrogateescape, which is not a guard here:
it rescues lone surrogates only, so an ordinary unencodable character
still raises. There is a test that pins exactly that, so this suite
notices if the platform ever changes.

Also corrects the _frames_for docstring, which I wrote in #3056. It says
the braille frames "raised UnicodeEncodeError inside the spinner's daemon
thread". They did not: unlike stdout, stderr's error handler is
backslashreplace, so the write never raised -- it printed the escape, and
the animation became a column of literal ⠋. The fix was right, the
reason given for it was not, and the difference between the two streams
is exactly what this change turns on.

print_streaming() writes to stdout the same way and has the same defect,
but it has no callers anywhere in the tree, so it is left alone rather
than changed without a way to exercise it.

Verified: 6 tests added to tests/test_ai.py, driven by real cp1252 streams
rather than mocks so the codec decides. Three mutations, all killed.
Full suite on Windows: the set of failing test names is identical before
and after (35 pre-existing).