Desktop jar ships a 0-byte linux libpython3.14.so (symlink) and a 252 MB unstripped .so.1.0 #74

Found by toolchain#22's desktop-e2e on ubuntu (UnsatisfiedLinkError: .../libpython3.14.so: file too short). The published desktop jar (3.14.7-alpha01) contains:

0          lib/linux-x86_64/libpython3.14.so        <- symlink in the PBS tarball, packed as an empty file
251884016  lib/linux-x86_64/libpython3.14.so.1.0   <- the real library, apparently unstripped
16800      lib/linux-x86_64/libpython3.so
19394064   lib/macos-aarch64/libpython3.14.dylib

manager.extractLibrary copies libpython3.14.so (the 0-byte entry) into the working directory (File(".", name)) and loads it.

Three defects:

1. Symlinks in the python-build-standalone archive become 0-byte jar entries; the jar must carry the real file under the name the loader asks for (resolve links when packing).
2. The linux library is ~250 MB vs ~19 MB on macOS; strip debug info when packing (or pick the stripped PBS variant) — measure before/after.
3. Extraction into the cwd writes into the user's directory and collides between apps/versions; extract into a per-version cache directory (and reuse it), or rely on SPEC L-9's packaged prefix first (Desktop: ship the stdlib with a packaged app (jar/jpackage), not only via PYTHONHOME for Gradle tasks #60).

Completion: a plugin/build test that fails when any lib/** entry in the desktop jar is 0 bytes or a symlink stub; the linux entry loads in a CI job on ubuntu with no PYTHONHOME; extraction no longer writes to the cwd.