Poetry's CLI has no --frozen equivalent. When frozen=True, poetry add/remove were running unmodified—resolving, locking, and installing despite the user requesting frozen mode.

Changes

• call_poetry_subprocess: When frozen=True and the command is add/remove, the function now (1) inserts --lock to skip installation, and (2) uses a _frozen_poetry_lock context manager to back up poetry.lock to a temp directory before the subprocess and restore it afterwards. This ensures pyproject.toml is updated while the lockfile remains truly frozen—even on subprocess failure.
• _frozen_poetry_lock context manager: Encapsulates the backup/restore lifecycle for poetry.lock. If the lockfile exists beforehand it is backed up and restored on exit; if it did not exist, any lockfile created during the block is removed. The temp directory is always cleaned up.
• _noop_context: No-op context manager used as a fallback when frozen mode is not applicable.
• Tests: 8 unit tests on call_poetry_subprocess (frozen add/remove, non-applicable commands, frozen=False baseline, lockfile restore on success, lockfile restore on failure, lockfile removal when it didn't previously exist, temp directory cleanup) + 2 integration tests on add_deps_to_group/remove_deps_from_group with Poetry backend under frozen mode. 100% coverage on the changed module.

# Poetry doesn't support a --frozen flag like uv does. To emulate frozen
# behaviour we: (1) pass --lock to skip installation, (2) back up
# poetry.lock before the subprocess and restore it afterwards so the
# lockfile is never modified.
frozen_applicable = usethis_config.frozen and args[:1] in (["add"], ["remove"])
if frozen_applicable:
    args = [args[0], "--lock", *args[1:]]