Fix lock --check falsely reporting stale when newer versions available

[petrkalos]

Summary

• hatch env lock --check (and hatch dep lock --check) incorrectly reports "Lockfile is not up to date" when a dependency has a newer version available on PyPI, even though the existing lock still satisfies all declared requirements.
• Root cause: UvLocker.in_sync() regenerates the lockfile into an empty temp file. Since uv pip compile has no existing pins to read from that empty file, it resolves from scratch and picks the latest versions — producing a diff whenever any package has a newer release.
• Fix: pre-seed the temp output file with the existing lock content before calling generate(). This leverages uv pip compile's default pin-preservation behavior (it reads pins from --output-file and keeps them when they satisfy the requirements). The check now only fails when inputs actually changed (new deps added, version ranges tightened, deps removed).

Test plan

• New unit test: test_uv_in_sync_preserves_pins_from_existing_lock — verifies temp file is pre-seeded so generate() can preserve pins
• New unit test: test_uv_in_sync_detects_stale_when_inputs_change — verifies that genuinely stale locks (e.g., range tightened beyond pinned version) are still detected
• New integration test: test_check_does_not_fail_when_newer_version_available — end-to-end with real uv: locks urllib3==2.0.0, widens to >=1.26, confirms --check passes
• Full test suite: 2342 passed, 72 skipped (1 pre-existing failure in venv tests, 22 pre-existing errors in publish tests — both unrelated)