uv

63338232 - Change the definition of `--locked` to require satisfaction check (#6102)

Change the definition of `--locked` to require satisfaction check (#6102) ## Summary This PR changes the definition of `--locked` from: > Produces the same `Lock` To: > Passes `Lock::satisfies` This is a subtle but important difference. Previous, if `Lock::satisfies` failed, we would run a resolution, then do `existing_lock == lock`. If the two weren't equal, and `--locked` was specified, we'd throw an error. The equality check is hard to get right. For example, it means that we can't ship #6076 without changing our marker representation, since the deserialized lockfile "loses" some of the internal marker state that gets accumulated during resolution. The downside of this change is that there could be scenarios in which `uv lock --locked` fails even though the lockfile would actually work and the exact TOML would be unchanged. But... I think it's ok if `--locked` fails after the user modifies something?