feat: Introduce TimelockOperation struct for secure and auditable delayed execution

[SynnekOG]

PR Description

Summary

This PR adds a new TimelockOperation struct to MultiSigContractV2.sol. The struct is designed to support governance and security mechanisms by enabling delayed transaction execution. It creates a standardized data model for storing, managing, and auditing timelocked operations.

---

Changes

• Added TimelockOperation struct with the following fields:

  • bytes32 id: Unique identifier for the timelock operation.
  • address target: Address of the contract or account the operation interacts with.
  • bytes data: Encoded transaction payload.
  • uint256 executeTime: Timestamp when the operation becomes executable.
  • bool executed: Tracks whether the operation has been executed.
  • bool cancelled: Tracks whether the operation has been cancelled.
  • string description: Human-readable description of the operation.

• Documentation

  • Added NatSpec comments for the struct for clarity and maintainability.

---

Rationale

• Governance Security
  Timelocks ensure stakeholders have time to review critical operations before execution, reducing the risk of malicious or rushed changes.

• Auditability
  By recording operation metadata (id, description, executeTime, and state flags), on-chain tracking and off-chain monitoring tools can provide full transparency.

• Flexibility
  The struct supports both upgradeability (future features like batching or priority execution) and usability for multi-sig workflows.

---

Impact

• No breaking changes to existing contract logic.
• Provides the foundation for implementing timelocked execution of sensitive operations (e.g., parameter updates, fund transfers).
• Enhances the governance model by aligning with best practices seen in protocols such as Compound, OpenZeppelin Governor, and others.

---

Next Steps

• Implement storage and management of TimelockOperation instances (e.g., mapping of id to operation).
• Add functions to:
  • Queue a timelock operation.
  • Cancel a pending operation.
  • Execute eligible operations after executeTime.
• Emit events for operation lifecycle (queued, executed, cancelled).
• Extend test coverage for:
  • Operation scheduling and expiry.
  • Correct handling of executed and cancelled flags.