Supersedes and includes #9105.

## Summary
- forward `install_before` to transitive Python package resolution when
`pipx:` tools are installed through uv
- pass uv's `--exclude-newer <timestamp>` flag on the uv install path
- pass pip's `--uploaded-prior-to <timestamp>` flag through `pipx
install --pip-args` on the pipx fallback path
- remove any inherited `PIPX_SHARED_LIBS` before invoking pipx so pipx
falls back to `PIPX_HOME/shared`
- update docs now that both uv and pipx install paths forward the cutoff
- add focused unit coverage for uv and pipx argument generation

## uv compatibility
`--exclude-newer` was added in astral-sh/uv#2166
and is included in https://github.com/astral-sh/uv/releases/tag/0.1.15,
so we do not need to check the uv version before using this flag.

## Why we can always use `--uploaded-prior-to`
`--uploaded-prior-to` was added in
pypa/pip#13625 and released in pip 26.0,
announced on January 31, 2026:
https://discuss.python.org/t/announcement-pip-26-0-release/105947. PyPI
currently lists pip 26.0.1 as the latest release as of April 17, 2026:
https://pypi.org/project/pip/.

pipx does not use a fixed bundled pip. It creates or reuses a shared
virtual environment containing pip and ensures that shared pip is
updated to the latest version:
https://pipx.pypa.io/stable/how-pipx-works/. In the current pipx source,
shared pip is installed/upgraded with `pip >= 23.1` and no upper bound,
so normal PyPI access gets the latest pip:
https://github.com/pypa/pipx/blob/main/src/pipx/shared_libs.py.

mise sets `PIPX_HOME` to the tool version's install path when invoking
the pipx fallback. That install path is prepared before the backend
runs: fresh installs create a new install directory, and `mise install
--force` uninstalls the existing version, removes the install path, and
recreates it before calling `pipx install`. With pipx's default
behavior, `PIPX_SHARED_LIBS` resolves to `<install_path>/shared`, which
is new for that install and can be initialized/upgraded by pipx to the
latest pip.

## Why unsetting `PIPX_SHARED_LIBS` is acceptable
`PIPX_SHARED_LIBS` is a real pipx override: it can point pipx's shared
pip virtualenv outside `PIPX_HOME`. pipx documents that it defaults to
`PIPX_HOME/shared`, but can be overridden:
https://pipx.pypa.io/stable/reference/environment-variables/. It can be
useful for deliberate CI caching or ephemeral `PIPX_HOME` setups, but it
only shares the packaging toolchain, especially pip. It does not make
installed pipx apps share their application dependencies.

For mise-managed `pipx:` installs, inheriting an external
`PIPX_SHARED_LIBS` is unsafe for this feature because it can point at an
older shared pip that does not support `--uploaded-prior-to`. It also
makes the mise install path no longer self-contained, because pipx app
venvs can contain absolute `.pth` pointers into that external shared
libs path. Moving, deleting, or changing that external path can break
later `pipx upgrade`, `pipx inject`, or `pipx runpip` operations.

I could not find public discussions indicating that users commonly rely
on `PIPX_SHARED_LIBS` for mise-managed pipx installs, and the default
pipx guidance is to leave it unset unless there is a specific reason. So
excluding this inherited variable for mise's pipx subprocesses should
not be breaking for most users, and it avoids a footgun where a global
shell/profile setting silently changes mise's install behavior.

Related pipx docs for shared pip maintenance:
-
https://pipx.pypa.io/stable/reference/examples/#pipx-upgrade-shared-examples
- https://pipx.pypa.io/stable/reference/cli/#pipx-upgrade-shared

## Tests
- `cargo fmt --check`
- `git diff --check`
- `cargo test -q uv_exclude_newer_args`
- `cargo test -q pip_uploaded_prior_to_args`

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>