v0.6.2

Fixed

• unix builds on riscv64 (any tag whose lib/libffi pin actually
  supports it, v1.24.0+) failed at the final link with ld: cannot find .../lib/libffi/out/lib/libffi.a, the same class of bug the
  RHEL ../lib64 fixup already covered — deplibs' own symlink fixup
  only ever checked one hardcoded path
  (out/lib64/libffi.a), but riscv64's own gcc -print-multi-os-directory
  answers ../lib64/lp64d (its own ABI-variant subdirectory), one level
  deeper than the RHEL case. The fixup now queries the real value live
  with the same compiler deplibs itself just used, instead of a value
  predicted in advance — live-verified against the real
  manylinux_2_39_riscv64 image end to end (a full build, real link,
  real binary).
• unix builds on riscv64 failed outright on every tag through
  v1.23.0 with configure: error: "libffi has not been ported to riscv64-unknown-linux-gnu.": lib/libffi's own submodule pin, on
  those tags, points to https://github.com/atgreen/libffi, a
  fork/mirror whose configure.host has no riscv* case at all
  (v1.24.0 moves the pin to the canonical libffi/libffi, which does
  — filed upstream, but there is no fix to backport onto a tag that has
  already shipped). MICROPY_PY_FFI=0 for exactly this (tag, riscv64)
  combination, and deplibs is skipped entirely rather than attempting
  a build that cannot succeed.
• unix builds failed on s390x/riscv64, on multiple tags, with a
  real GCC diagnostic in ports/unix/main.c:
  error: variable 'path_remaining' might be clobbered by 'longjmp' or 'vfork' [-Werror=clobbered]. The same diagnostic class record [0044]
  found narrower (mpy-cross's own main.c, s390x, v1.28.0 only)
  and descoped by identifier rather than suppressed — this sweep found
  it in the port's main.c too, on multiple tags, on both
  architectures, which is what moved it from "worth descoping two
  identifiers for" to "worth suppressing at the architecture level" via
  -Wno-error=clobbered, the same escalation aarch64's own
  -Wno-error=array-bounds entry already went through once.
• unix's new -Wno-error=<diagnostic> gcc probe still failed
  manylinux_2_41_mipsel builds on every pre-v1.26.0 tag, the one
  case the probe was written for: it always probed the image's bare
  gcc, but mipsel's own image is a Bootlin cross-toolchain where the
  real build compiler is mipsel-linux-gnu-gcc (gcc 14.3.0) — a
  different, older binary than whatever bare gcc resolves to inside
  that same image. The probe's own false-positive verdict (from the
  native image gcc, disproving this project's own prior assumption that
  every Bootlin/xpack toolchain here was already gcc >=15) let
  -Wno-error=unterminated-string-initialization back into
  CFLAGS_EXTRA, and the real cross-compiler rejected it exactly as any
  other gcc-14 would. Fixed by probing the actual compiler each build
  step uses: bare gcc for the in-container mpy-cross build (a host
  tool, never cross-compiled), {cross_compile}gcc for the main port
  build — identical for every arch but mipsel.
• **unix builds failed outright on every clone-path tag that needs