pureboot: drive the serial port on Windows too

The host tool was standard-library-only but POSIX-only with it: termios and
select() bound the port layer, and importing termios failed outright on
Windows, so the module could not even load there.

Split Port into PosixPort (unchanged) and a WindowsPort over the Win32 serial
API through ctypes, picked by os.name; every call site keeps the Port name.
kernel32 only, so the standard-library constraint holds.

Windows has no select() for a COM handle, so the read deadlines move into the
driver as COMMTIMEOUTS, re-armed per read: read_available() ends on a gap
longer than a USB-serial latency timer coalesces (16 ms on FTDI parts),
read_exact() on the count or its deadline. Opening asserts DTR and RTS as a
POSIX open does, so a board wiring DTR to reset still pulses it. A failed
configuration closes the handle before raising - a COM handle is exclusive,
and the leak met the next open as "Access is denied". Win32 takes any integer
baud and a driver may accept one its hardware cannot produce (an FT232R
reports back a baud of 3 and keeps the old divisor), so obvious nonsense is
refused where termios' table would have.

Tested against an ATmega328P on COM6: info, fuses, both memories programmed
and verified, session reconnect, hand-over, the loader self-update, and the
write guard on its own slot. test_planner runs on Windows now as well.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

pureboot/README.md

@@ -150,8 +150,13 @@ reflashing the application. The mega needs its fuses for the preflight
 
 ## Host tool
 
-`pureboot.py` — Python 3, standard library only (termios drives any tty,
-a USB adapter as well as a simavr pty):
+`pureboot.py` — Python 3, standard library only. The port layer is the one
+platform-specific part: termios drives any tty on POSIX (a USB adapter as
+well as a simavr pty), the Win32 serial API through `ctypes` drives a COM
+port on Windows (`--port COM6`; the `\\.\` form for two-digit ports is
+supplied by the tool). Opening the port asserts DTR and RTS on both, so a
+board that wires DTR to reset gets its reset pulse and opens the activation
+window by itself.
 
     pureboot.py --port /dev/ttyUSB0 --baud 57600 \
         --info --fuses --flash app.hex
@@ -192,3 +197,7 @@ Per chip preset, `ctest` runs:
   then every power-fail phase: the device is killed mid-write, restarted
   from its flash dump, and a re-run must complete the update with the
   application intact throughout.
+
+`size`, `pi`, and `planner` are host logic and run anywhere; the three
+simulator-driven targets need simavr and a pty, so they are POSIX-only —
+on Windows the tool is exercised against real hardware.