build(uv) Exempt libvcs from the global exclude-newer cooldown

why: ``uv sync --upgrade`` (and a fresh ``uv sync`` on an empty venv)
fails for any contributor whose user-level ``uv.toml`` carries an
``exclude-newer`` cooldown shorter than the gap between a libvcs
release and a vcspull bump. The default 3-day cooldown is exactly the
window where the two repos move together, so the symptom shows up
every time libvcs ships and vcspull pins the new version on the same
day. Workarounds via ``--exclude-newer-package libvcs=...`` on every
command don't compose with editor / pre-commit / CI flows that just
run plain ``uv sync``.

what:
- ``pyproject.toml``: add ``[tool.uv.exclude-newer-package]`` with
  ``libvcs = false``. The ``false`` form exempts libvcs from any
  ``exclude-newer`` constraint without baking a date into the project
  config, so the override doesn't age and doesn't need maintenance
  when the next libvcs release lands.
- ``uv.lock``: refresh the ``[options.exclude-newer-package]`` block
  so it records ``libvcs = false`` (sourced from pyproject) instead
  of the ad-hoc ``2026-04-26T00:00:00Z`` timestamp that landed when
  the original lock was forced through with a CLI flag.
- Behaviour: contributors run plain ``uv sync`` / ``uv sync --upgrade``
  without flags or per-user config tweaks; the rest of the global
  cooldown still applies to every other dependency.

Author: tony

pyproject.toml

@@ -135,6 +135,14 @@ typings = [
 requires = ["hatchling"]
 build-backend = "hatchling.build"
 
+[tool.uv.exclude-newer-package]
+# vcspull's release cadence is tightly coupled to libvcs -- a libvcs
+# release blocking on a 3-day cooldown blocks every contributor's
+# ``uv sync`` until the cooldown clears. ``false`` exempts libvcs from
+# any ``exclude-newer`` constraint (global or per-user) without
+# committing a date that would age into the lockfile.
+libvcs = false
+
 [tool.mypy]
 python_version = "3.10"
 warn_unused_configs = true