feat: 4055 Implement Owner Management for Smart Contracts

[nosid91]

Description

This PR implements a secure mechanism to transfer and manage the OWNER role in Guardian smart contracts to address security audit findings (#4055).

• Add two-step ownership transfer pattern in Access.sol (proposeOwner, claimOwner, removeOwner)
• Add Guardian CLI commands for owner management (propose-owner, claim-owner, remove-owner)
• Add comprehensive test suite for ownership transfer scenarios
• Document owner management workflow in contracts README

Related issue(s)

Fixes #4055

Notes for Reviewer

Why Two-Step Ownership Transfer?

The implementation uses a two-step ownership transfer pattern (propose + claim) instead of direct transfer for the following security reasons:

1. Prevents accidental transfers: Direct ownership transfer to an incorrect address (typos, copy-paste errors) would result in permanent loss of contract control. The two-step pattern requires the new owner to actively claim ownership, confirming they have access to the destination address.

2. Validates recipient capability: The claim step verifies that the new owner can actually execute transactions, ensuring they have the private key and proper account setup.

3. Provides recovery window: If an owner accidentally proposes the wrong address, they can simply propose a different address to overwrite the pending owner before the claim occurs.

4. Industry standard: This pattern is widely adopted in production contracts (OpenZeppelin's Ownable2Step, major DeFi protocols) as a security best practice.

Security Constraints

• Owners cannot remove themselves (prevents accidental lockout)
• Contract address cannot be removed as owner (maintains internal call capability)
• pendingOwner is cleared after successful claim (prevents replay)

Backwards Compatibility

• Existing deployed contracts are not affected
• No changes to existing public interfaces

Checklist

• Documented (Code comments, README, CLI help)
• Tested (integration tests with Hedera local node)

[andrewb1269]

Approve the two package.json files. Please ensure other folks review the other files in the PR. Thank you!

[andrewb1269]

Putting a block here until another reviewer also approves. Please @ me and I can remove the block once another reviewer approves the PR.

[kirill-tolochko]

Hello. I was checking your PR 5655 and found that there are errors after Wipe contract creation, and Retire contract cannot be created. I tried to create both in UI. There is a error like this:

2026-02-09T13:43:02.133Z [GUARDIAN_SERVICE]: TypeError: no matching event (argument="key", value="0xbca31226f48d9d9a4c4759ba05c7e55d4d155ef264dd1e7f462df37b89647fa9", code=INVALID_ARGUMENT, version=6.15.0)
at makeError (file:///C:/guardian/guardian-service/node_modules/ethers/lib.esm/utils/errors.js:125:21)
at assert (file:///C:/guardian/guardian-service/node_modules/ethers/lib.esm/utils/errors.js:151:15)
at assertArgument (file:///C:/guardian/guardian-service/node_modules/ethers/lib.esm/utils/errors.js:162:5)
at Interface.getEventName (file:///C:/guardian/guardian-service/node_modules/ethers/lib.esm/abi/interface.js:527:9)
at syncWipeContract (file:///C:/guardian/guardian-service/dist/api/contract.service.js:327:40)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Object.syncWipeContracts (file:///C:/guardian/guardian-service/dist/api/contract.service.js:298:9)
at async CronJob.taskExecution (file:///C:/guardian/guardian-service/dist/helpers/synchronization-task.js:56:29)

Also I've found that this issue was already presented in the 4054 story commit dd244b1

Could you please take a look?

Steps:

1. deploy new Wipe, Retire, RetireSingleToken, RetireDoubleToken

2. Update contracts ids in the .env.guardian
   RETIRE_CONTRACT_FILE_ID="0.0.6371646"
   WIPE_CONTRACT_FILE_ID="0.0.6371642"
   RETIRE_SINGLE_FILE_ID="0.0.6371651"
   RETIRE_DOUBLE_FILE_ID="0.0.6371652"

3. Restart guardian service (if it is running already or just start everything), try to create new wipe contract and new retire contract