hardhat-deploy tracking or manual existence checks for idempotent retries

Goal: retry a failed contract write on Hardhat Network without creating a duplicate deployment or unintended state change.

Hardhat core provides no built-in idempotency guard for ethers deployment calls, so retrying after a failed write may deploy a second contract unless the script checks for an existing deployment. hardhat-deploy tracks deployments in artifacts/deployments and skips contracts whose address and bytecode already match, but it is a third-party plugin with its own file conventions and version-dependent behavior. A manual, plugin-free approach requires custom address-book or on-chain existence logic for each contract, and Hardhat Network mempool replacement semantics do not guarantee that a retried write always supersedes the original across mining modes. hardhat_reset is not selective and discards all local chain state.

Assumption: behavior varies by installed Hardhat release and hardhat-deploy version. Which constraint should decide the trade-off: plugin operational overhead or per-contract manual verification logic? Is on-chain existence checking sufficient to prevent duplicate state changes when a failed transaction remains pending in the mempool?