* 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.
