[NF-17] [CONTRACT] Governance Proposal Rate Limiting

Overview

The Strategist can currently call propose() as many times as they want, for as many different pools as they want, in the same ledger. This issue adds a cooldown to prevent proposal spam that could overwhelm the Guardian's ability to meaningfully review each one within the 72-hour veto window.

Problem

Governance.propose(pool_id, target_bps) has no rate limit — the only per-proposal protection is the existing audit-fixed behavior where amending a pending proposal for the same pool restarts its own clock (fix M-03). There's nothing stopping the Strategist from proposing changes to 20 different pools in the same block, effectively burying the Guardian in simultaneous 72-hour windows and diluting real review capacity.

Proposed Solution

• Add DataKey::LastProposalLedger to Governance.
• Add a governance-configurable MIN_PROPOSAL_INTERVAL_LEDGERS (e.g. a few hours' worth of ledgers).
• propose() rejects with a new ProposalRateLimited error if current_ledger < last_proposal_ledger + MIN_PROPOSAL_INTERVAL_LEDGERS, regardless of which pool the new proposal targets.
• Update last_proposal_ledger on every successful propose() call (including amendments, since those already restart their own clock per M-03 but should also respect the global rate limit).

Acceptance Criteria

• A second propose() call within the cooldown window is rejected, even for a different pool than the first
• A propose() call after the cooldown has elapsed succeeds normally
• The rate limit interval is configurable (not a hardcoded magic number with no setter)
• Existing single-proposal-lifecycle tests continue to pass unmodified
• Unit tests cover: rate-limited rejection, successful proposal after cooldown, rate limit applying across different pool_ids

Start by locating the Governance::propose entry point, the existing DataKey definitions, and the single-proposal-lifecycle tests. Trace how proposal errors, configuration, ledger values, and amendments are handled; done means the configurable cooldown rejects rapid proposals across pool_ids, allows proposals after it elapses, and has focused unit-test coverage without breaking existing lifecycle tests.