Use Lock::from_toml consistently, check version

[woodruffw]

Summary

See #20921 (comment) for context.

This accomplishes two goals:

• We now use the faster lockfile parsing path when parsing tool installation lockfiles
• We now correctly validate the lockfile's version in uv tool subcommands, which is consistent with what the project commands do

Test Plan

Added a test demonstrating the change. The behavior from the change is arguably surprising, though: ToolLock::read silently skips the lockfile if it's invalid, which includes our new version check. Arguably that should be stronger, i.e. we should reject if the lockfile is malformed (or at least warn?).

[woodruffw]

Sorry, re-requesting review since I changed the approach 😅

[astral-sh-bot]

uv test inventory changes

This PR changes the tests when compared with the main base revision.

• Added tests: 2
• Removed tests: 0
• Changed suites: 1

uv-resolver: +2 / -0

Added:

• uv-resolver::lock::deserialize::tests::unparsable_unsupported_lock_version_is_identified
• uv-resolver::lock::deserialize::tests::unsupported_lock_version_is_rejected

Removed: none

[zsol]

thanks, this looks great! Gotta make sure the pub fields we just hid aren't used by known projects that use our crates

[woodruffw]

Took a quick look at the reverse deps on crates.io and couldn't find any third-party users of uv-resolver. But there might be a better place to discover our downstreams that I'm not aware of 🙈