feat: implement emergency dispute window functionality and related tests

[T-kesh]

Closes #569

What changed
Emergency proposals now carry a dispute window — a configurable period after creation during which the action cannot yet be confirmed, giving the admin time to cancel a mistaken or malicious proposal.

emergency.rs

Added dispute_deadline: u64 and cancelled: bool to EmergencyProposal
lib.rs

propose_emergency_action — stamps dispute_deadline = now + window on every new proposal; includes the deadline in the emrgprop event
confirm_emergency_action — now Result<(), VaultError>; returns DisputeWindowActive if the window hasn't elapsed, ProposalCancelled if the proposal was cancelled
cancel_emergency_action — new admin-only function; emits emrgcncl; returns DisputeWindowClosed if the window already elapsed
set_emergency_dispute_window(seconds) / emergency_dispute_window() — admin getter/setter for window duration (default 3600 s / 1 hour)
New error codes: DisputeWindowActive (18), ProposalCancelled (19), DisputeWindowClosed (20)
New DataKey::EmergencyDisputeWindow
storage_registry.rs — EmergencyDisputeWindow registered under the Emergency namespace

Tests
Updated test_dual_approval_emergency_pause to advance time past the window. Added 6 new tests:

confirm blocked during window
confirm allowed after window
admin cancel succeeds during window
cancelled proposal rejected even after window passes
cancel rejected after window closes
custom window duration respected

[drips-wave]

@T-kesh Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[T-kesh]

@Junirezz Kindly review