Wheel packaging and manylinux audit for bundled Python packages

[timholy]

Currently, `build_library(...; bundle = true)` produces a self-contained Python package that `pip install` works on, but the resulting wheel is a generic sdist/wheel with no platform tag. `docs/src/index.md` explicitly defers this:

Wheel-level packaging (platform tags, `manylinux` audit) is out of scope for the current MVP — `pyproject.toml` builds a generic sdist/wheel and the developer is responsible for any platform tagging the distribution target requires.

For PyPI distribution to work in practice, the wheel needs a real platform tag (`manylinux_2_28_x86_64`, `macosx_11_0_arm64`, etc.) and its native dependencies need to satisfy the corresponding ABI policy. The bundled `libjulia` + JLLs may pull in glibc symbols newer than the `manylinux` baseline; `auditwheel repair` will need to be part of the build flow.

Work items

• Run `auditwheel show` against a bundled wheel built on Linux and inventory the symbol/version violations against the current `manylinux_2_28` policy.
• Decide whether to `auditwheel repair` (bundling more `.so`s and rewriting RPATHs) or to require a newer baseline (`manylinux_2_34`).
• Same investigation for `delocate` on macOS and `delvewheel` on Windows.
• Wire the auditwheel step into the reusable workflow from Ship a reusable GitHub Actions workflow for downstream wrapped-library builds #37.
• Document the resulting wheel-tag story.

Gated on #37 (the build pipeline itself) producing wheels at all. Not a release blocker for the JLW package; it is a release blocker for the "users actually get pre-built wheels from PyPI" story, which is plausibly important enough to track explicitly.