v1.10.0 "Atelier"

Sixth release of the RustyNES-parity roadmap: HD-pack emu-thread wiring.

Fixed

• HD texture packs (v1.3.0) were never wired into the emu-thread build —
  app.rs's synchronous render path composited an active pack via
  hd_compositor::composite before its own drop(emu), but the threaded build's
  emu_thread::drive_one had no equivalent step, so a threaded build with a pack
  selected silently rendered the native (uncomposited) framebuffer
  (docs/frontend.md's documented scope cut, closed here). drive_one's
  plain-frame (run-ahead-disabled) branch now composites before publishing to
  PresentBuffer; the common no-pack-active case stays exactly as fast as before
  (a cheap hd_pack_name() &self pre-check, no extra allocation) since the real
  compositing cost only applies once a pack is actually selected. Found in review
  (#90): the lock is now released before the PresentBuffer copy in this branch
  too, matching the run-ahead branch's existing drop(emu)-before-publish pattern.

Deferred (honestly scoped, not silently dropped)

• The in-app HD-pack Builder GUI (browsing the live TileTag stream,
  assigning replacement PNGs, writing pack.toml + assets) needs a new
  core-side "reconstruct RGBA pixels for a given tile hash" API that doesn't
  exist yet — the tile-identity hash doesn't reverse to a VRAM location, so
  authoring support is a genuinely separate, substantial piece of work from the
  emu-thread wiring fix above. Pushed to a later, explicitly-scoped release.
  See to-dos/VERSION-PLAN.md's v1.10.0 section.
• HD-pack compositing is deliberately NOT applied to emu-thread's run-ahead
  branch. Found in review (#90): step_with_run_ahead's returned frame is a
  PEEKED frame (captured, then rolled back so emu's persisted state only
  advances by one real frame), but EmuCore::hd_pack_composite_inputs reads
  Ppu::tile_tags() from emu's CURRENT (post-rollback) state — a different
  frame than the peeked bytes. Compositing with a mismatched (fb, tags) pair
  would silently apply replacement tiles keyed to the wrong frame, corrupting
  the picture rather than just showing native art, so this rung skips
  compositing there instead. The same desync already exists, unfixed, in
  app.rs's synchronous render path (pre-existing since run-ahead and
  HD-pack were first combined; not introduced by this release, not touched by
  it either) — both are tracked together as a v1.10.x/later follow-up in
  to-dos/VERSION-PLAN.md. Run-ahead and HD-pack are each off by default, so
  this only affects the narrow case where a user has both features enabled
  simultaneously.