fix: Windows stability issues (console encoding, camera enumeration, …

[ZouzouWP]

Four separate crashes that only show up on Windows with real hardware attached. Grouped in one PR because they were all found the same week, not because they're related — happy to split if preferred.

1. Console encoding crash (cp1252)

Symptom: an emoji in a log/print line could raise an unhandled UnicodeEncodeError on a Windows console using the legacy cp1252 code page, turning an endpoint into a blank 500 with no useful message reaching the frontend.

Fix: stdout/stderr are reconfigured with errors="replace" at import time, so unencodable characters degrade instead of crashing the process.

2. Camera list sometimes empty

Symptom: /available-cameras would intermittently return an empty or wrong list, depending on which FastAPI worker thread handled the request.

Root cause: pygrabber enumerates cameras via COM, which must be initialized per-thread. FastAPI's thread pool never did that, so enumeration silently failed on threads that hadn't.

Fix: explicitly initialize/uninitialize COM around the enumeration call.

3. Recording crashes with "no status packet"

Symptom: recording sessions aborted mid-way with a serial ConnectionError, non-deterministically, on otherwise-healthy hardware.

Root cause: the default video encoder (libsvtav1) is CPU-heavy enough that two parallel encode streams could starve the motor-bus read loop of CPU time.

Fix: default to h264/ultrafast, measured ~11x faster to encode on this hardware.

4. Real errors hidden behind "check logs"

Symptom: any recording failure showed the same generic message to the user — the real exception (exactly what let us diagnose #2 and #3 above) never left the server logs.

Fix: /recording-status now includes the actual exception message.

Testing

Each fix corresponds to a crash reproduced and captured in server logs beforehand, then confirmed resolved after the change.