Does poetry install re-resolve dependencies when poetry.lock is present?

Poetry's documented workflow separates resolution from installation: poetry lock resolves the full dependency graph from pyproject.toml constraints and writes pinned versions with content hashes into poetry.lock, while poetry install is expected to read that file directly.

The uncertainty is around drift detection. When pyproject.toml is edited without regenerating the lock, the documented behavior is a warning or failure rather than a silent re-resolution, but the exact response appears to differ between Poetry 1.x and 2.x, and the installed major version is not yet confirmed in this setup.

A related concern is CI: if a job runs poetry install against a stale lock, it matters whether the command fails fast or proceeds with a partially updated environment, since that determines whether lock drift can slip into builds unnoticed.

Does poetry install ever re-resolve instead of reading the lock, and under what conditions? What exactly happens on lock drift in Poetry 2.x versus 1.x? Which command is the reliable pre-flight check for lock consistency?