Add `DelayedExecution` (Timelocked Accounts) to `AuthMultisigSmart`

## Delayed Execution Overview

### What it adds

`AuthMultisigSmart` lets the account procedures into a delayed execution mode through `ProcedurePolicy`. Each policy carries one of three `ProcedurePolicyExecutionMode` values:

- `ImmediateOnly`: procedure runs directly in the current tx (one immediate threshold).
- `DelayOnly`: procedure runs only through a propose / wait / execute (one delay threshold).
- `ImmediateOrDelay`: both are allowed: The delay threshold must be ≤ the immediate threshold (lower-quorum trade for waiting).

The timelock parameters live in `DelayedExecutionPolicy`:

- `min_delay`: minimum wait between propose and execute.
- `propose_expiration_delta`: lifetime of a proposal before it expires.

### Lifecycle: simulate → propose → wait → execute

The flow follows the pattern discussed in both https://github.com/0xMiden/protocol/issues/2211 and https://github.com/OpenZeppelin/guardian/discussions/61.

1. **Simulate.** The user runs the target tx (e.g. calls `rotate_key`).

2. **Propose.** Once the proposer has the summary commitment, they construct a propose tx that calls `propose_transaction(TX_HASH)`. Other cosigners independently re-simulate step 1 to verify the summary matches their intent before signing. The propose tx itself is gated by multisig threshold, only when enough cosigners sign does `finalize_timelock_proposals` write the proposal entry. Cosignatures can be collected after the propose tx is broadcast, they don't all need to be present up front.

3. **Wait.** The proposal sits in storage until `min_delay` passes, but no longer than `propose_expiration_delta`. During this window, signers may also call `cancel_transaction_proposal` (gated by a separate cancel quorum recorded at propose time) or `cancel_and_propose_new_transaction` to swap one proposal for another.

4. **Execute.** Once the delay has elapsed, the user re-runs the original tx, this time wrapped in `execute_proposed_transaction`. The auth procedure re-derives the same `TX_SUMMARY_COMMITMENT`, matches it against the stored proposal, asserts the unlock timestamp has been reached, and clears the entry. The original procedure runs normally.

The `DelayedExecutionPolicy` itself is rotatable via `update_delayed_execution_policy`, which is treated as any other admin procedure and can itself be placed under a delayed policy.

### Auth-path finalization

After signature verification, `finalize_timelock_proposals` triggers the pending slots in this order:

1. **execute**: if `PENDING_EXECUTE_SLOT` is set and `requires_delay = 1`, enforce the timelock and remove the matched proposal.
2. **cancel**: if `PENDING_CANCEL_SLOT` is set, verify the cancel quorum is met by `num_verified_signatures`, then remove the proposal entry.
3. **propose**: if `PENDING_PROPOSE_SLOT` is set, assert no proposal already exists for that hash, then write a new proposal entry.

All three pending slots are cleared at the end of `auth_tx`.