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?

scripts/scenarios/templates/lock.mustache

@@ -80,19 +80,6 @@ fn {{module_name}}() -> Result<()> {
         .arg(packse_index_url())
         .assert()
         .success();
-
-    // Assert the idempotence of `uv lock` when resolving with the lockfile preferences,
-    // by upgrading an irrelevant package.
-    context
-        .lock()
-        .arg("--locked")
-        .arg("--upgrade-package")
-        .arg("packse")
-        .env_remove("UV_EXCLUDE_NEWER")
-        .arg("--index-url")
-        .arg(packse_index_url())
-        .assert()
-        .success();
     {{/expected.satisfiable}}
 
     Ok(())