That's true when running `cargo install` to install an application directly from crates.io, but not when running `cargo build` in an already checked-out repository.
A cargo build ends up there calling into the resolver’s resolve_ws_with_opts() which would refresh the lockfile.
Not resolve_with_previous() which would use the lock file as-is.
The only reason this sticks in my mind is i ran into an issue building bat after i made some changes, i obviously assumed it was my changes so went through the process of debugging and backing out my changes until finally i was back to a virgin branch and still failing - passing —frozen —locked fixed it.
