feat(uv): let builds declare their execution fleet's platform identity for PEP 517 frontends

## Context

`pep517_frontend` (#1483) resets `platform_libc`/`platform_version` inside the frontend's exec configuration so its Python build dependencies resolve for the platform it executes on. The reset values default to the host repository rule's probe (`CURRENT_PLATFORM_*`) — exact whenever the execution platform is the host (every local build), an approximation under remote execution with workers unlike the client. No analysis-time source of truth exists for a foreign worker's libc or version: that is why these are flags rather than constraints.

The wrapper already carries the escape hatch — `libc` and `platform_version` attributes that the reset transition reads — but since #1484 wires the wrapper into *generated* sdist repositories, **nothing lets a user set those attributes**: the generated `pep517_frontend(name = "frontend", actual = ":build_tool")` target hardcodes the defaults.

Raised by review on #1484 (`repository.bzl` thread: "generated repositories provide no way to set the wrapper's libc or platform_version escape-hatch attributes").

## Proposal

Thread execution-fleet platform identity into the generated wrapper target. Two candidate shapes:

1. **Hub-level setting** (preferred?): the execution fleet is a property of the *build*, not of any one package — e.g. `uv.configure(exec_platform_libc = ..., exec_platform_version = ...)` flowing into every generated `sdist_build` repo's frontend target.
2. **Per-package** via `uv.override_package(...)`, consistent with how other sdist knobs (patches, toolchains, env) are plumbed — more mechanism than the problem needs, but zero new surface.

Either way the default stays the host probe, so local builds are untouched.

## Acceptance

- A workspace whose remote workers differ from the client (e.g. macOS client, linux/glibc fleet) can declare the fleet's `libc`/`platform_version` once and have every generated frontend resolve its build deps for the worker.
- Analysis test pinning that the declared values reach the frontend's configuration (the `flag_probe` harness from #1482 already measures this).
- Docs note replacing the current "remote workers unlike the client are unsupported for sdist builds" caveat with the new knob.