[5/n][guardian-integration] unify Step 2 / Step 3 withdrawal timestamp

[0xsiddharthks]

Stacked on #423 (siddharth/guardian-integration).

Summary

Step 2 (commitment pre-check) and Step 3 (guardian hard reserve) used different timestamps — Step 2 read the leader's checkpoint_timestamp_ms, while Step 3 read the on-chain WithdrawalTransaction.timestamp_ms set by Move's clock.timestamp_ms(). They could drift by seconds, and Step 2 could pass while Step 3 failed after the user's balance was already burned. This PR unifies them.

• Rust: WithdrawalTxCommitment gains timestamp_ms: u64; the leader fills it with its checkpoint timestamp when building the commitment. Step 2's capacity_at now reads approval.timestamp_ms / 1000 — same source as Step 3.
• Proto: SignWithdrawalTxConstructionRequest.timestamp_ms added.
• Validator check: validate_withdrawal_tx_commitment rejects the commitment before BLS-signing if the leader's timestamp differs from this node's latest checkpoint by more than 5 minutes — catches both far-future (capacity theft) and far-past (stuck-forever DoS) values.
• Move: WithdrawalCommitmentMessage carries timestamp_ms; commit_withdrawal_tx takes it as a parameter and includes it in the BLS-verified message. new_withdrawal_txn drops clock: &Clock in favour of timestamp_ms: u64, so the on-chain value is exactly what the committee signed.

Test

• cargo nextest run -p hashi-types -p hashi-guardian -p hashi — 327/327.
• sui move test in packages/hashi — 74/74.
• make fmt && make clippy — clean.

[bmwill]

We should avoid any timestamps that can be manipulated and are set other than by reading the onchain clock.