v0.7.3

Changed

• The two toolchain pins [0046]'s weekly checker reported behind are moved:
  llvm-mingw 20260616 -> 20260908 (docker/windows.Dockerfile) and emsdk
  6.0.8/9d70dbe8 -> 6.0.9/f04ea239 (docker/webassembly.Dockerfile).
  Both sha256s recomputed from the real tarball, and each one's internal layout
  re-checked with tar tJf rather than carried over from the previous version:
  llvm-mingw still unpacks to a single top-level directory (what
  --strip-components=1 assumes) and still ships all four
  <arch>-w64-mingw32- bin/ prefixes build_windows.py drives; the emsdk
  tarball still has the install/emscripten + install/bin shape the image's
  own ENV PATH points at. bin/update_toolchains.py --check now reports
  every pin current. Nothing about the emsdk bump touches
  [usermod.webassembly], which deliberately records no emsdk version at all
  ([0092]) -- MicroPython's own tools/ci.sh has never pinned one.
• Both bumped RUN steps stopped claiming to track a deleted file. Each
  said it was "pinned to resources/usermod.toml's own [llvm-mingw]/[emsdk]
  table -- keep the URL and sha256 in step with it", directly contradicting the
  "This file is the pin of record" paragraph a few lines above it in the
  same file: [0092] deleted resources/usermod.toml, and usermod/llvmmingw.py
  / usermod/emsdk.py went with the bare-host resolvers ([0050]/[0042]). The
  webassembly one also cited open-questions.md's "nothing checks whether a
  pinned version is stale" note, which [0046] and pin-staleness.yml made false
  -- that checker is precisely what found both of these.