Host client: progress callback for long-running wire transfers (SCREENSHOT especially) #53

Problem

SCREENSHOT's own docs are explicit that a capture over serial can
take anywhere from several seconds to several minutes (see
server/README.md's transfer-time table: up to ~9 minutes at 9600
baud for a capture at the AMIP_SCREENSHOT_MAX_BYTES cap) — and even
over TCP or Amiberry's serial-to-TCP bridge, a real capture is a
noticeably long blocking call. Amipilot.screenshot() (and WireClient
generally) gives the caller zero feedback while this is happening:
the call just blocks until the full payload has arrived, with no way
to know it's 10% done vs. hung.

Confirmed hands-on during real Picasso96/uaegfx hardware-adjacent
testing on Amiberry this session: driving SCREENSHOT against a real
P96 CLUT and truecolor screen each took tens of seconds with no
visible progress at all, and it wasn't obvious from the caller's side
whether the command was still working or had stalled.

Proposed design (sketch)

• WireClient._read_exact() (host/amipilot/wire.py) is the natural
  hook point: it already loops accumulating bytes via _recv() (up to
  4096 bytes per call) until count bytes are buffered. An optional
  on_progress: Callable[[int, int], None] | None parameter
  (bytes-so-far, total) invoked after each _recv() iteration would
  cover every large-payload wire read generically (SCREENSHOT,
  FSGET, and any future binary-payload verb), not just screenshots.
• Thread that optional callback up through WireClient.command() and
  Amipilot.screenshot()/fs_get() as an optional keyword argument
  (e.g. client.screenshot(window="...", on_progress=lambda done, total: ...)),
  defaulting to None (today's exact behavior, zero overhead when
  unused).
• Consider a small built-in helper for the common case (print a simple
  X/Y bytes or percentage line to stderr) so scripts don't all have
  to hand-roll the same thing, without forcing it on callers who want
  their own UI.

Why now

Filed while running real hardware-adjacent P96/SCREENSHOT verification
on Amiberry (Picasso96 3.6 + uaegfx) — the lack of any progress
feedback during a long capture was a genuine, felt annoyance doing
this by hand, not a hypothetical.