feat: Provision managed uv on native Windows x64 (#14749)
Setup now installs the locked uv release on native Windows x64 from the
verified official zip and exports `uv.exe` and `uvx.exe` into the
managed bin.
Part of TURBO-6379.
Based on the level-2 integration branch (#14745). It will be rebased
onto `main` after its prerequisite stacks merge: the uv/Python adapter
stack (#14533 through #14670, #14691, #14649 activation, #14735 `uv
sync`) and the Windows provisioning stack (#14582, #14584, #14659).
The official Windows zip is flat and its binaries are self-contained, so
they are exported as the Store's hard links instead of the Unix shell
launchers. Programs that start `uv` without a shell (Python's
`subprocess`, Node's `spawn`, Rust's `Command`) still find it, and
`uvx.exe` starts the `uv.exe` exported beside it. Activation already
gives `turbo run`, `turbo exec` and setup's own `uv sync` the launchers'
settings (`UV_PYTHON_INSTALL_DIR`, `UV_PYTHON_DOWNLOADS=never`, plus
`UV_PYTHON_PREFERENCE`/`UV_PYTHON` with managed Python), now with the
ordinary path spelling rather than a verbatim `\\?\` path.
```diff
.turbo/tools/generation-…/
bin/
- uv -> ../tools/uv/launch-<hash>/uv (sh launcher, Unix)
+ uv.exe (hard link to tools\uv\uv.exe, Windows x64)
+ uvx.exe (hard link to tools\uv\uvx.exe)
tools/uv/
+ uv.exe uvw.exe uvx.exe (full verified tree)
```
```text
UvPlan::from_lock(lock, platform)
macOS, GNU Linux -> launcher plan (unchanged)
Windows x64 -> .exe exports, zip with no root
Windows arm64, musl -> UnsupportedTarget
prepare / stage
only on the host family the plan was built for
```
- Official uv Windows zips mark each entry "not content indexed" (DOS
attribute `0x2000`), which the strict ZIP reader rejected. It is now
ignored like the archive bit; reparse points and other attributes stay
unsupported.
- `test_support::stored_zip_entries` builds multi-entry fixture zips
(`stored_zip` keeps its bytes).
- Linux and macOS behavior is unchanged.
I checked the real `uv-x86_64-pc-windows-msvc.zip` (uv 0.13.0) against
the uv layout in a sandbox: rejected before this change, extracted
`uv.exe`, `uvw.exe` and `uvx.exe` after. On a Windows 11 VM (x64 under
emulation), the hard-linked `uvx.exe` started the exported `uv.exe`
beside it.
