poetry.lock stores a content-hash computed from the dependency section of pyproject.toml. When they disagree, poetry install fails with pyproject.toml changed significantly since poetry.lock was generated. Run poetry lock to fix the lock file.
The check is a hash of the declared constraints, not of resolved versions, so it fires on any edit to a dependency line even when the resolution would not change, and it does not fire on unrelated edits such as the description. A merge that takes both sides of a dependency change is the usual cause, since the lock is regenerated by only one branch.
Run poetry lock to recompute. In Poetry 2.0 that command refreshes the lock while keeping already-locked versions where they still satisfy the constraints, so it is not the same as upgrading everything; poetry lock --regenerate discards the existing pins and re-resolves from scratch. In CI, poetry check --lock verifies the pair without installing anything, which turns a stale lock into a fast, obvious failure instead of a slow install error.