Measure pallet timeouts in relay chain blocks, not parachain blocks

[bkontur]

Problem

All timeouts, expiries, periods and intervals in the storage provider pallet (and drive-registry pallet) are measured in parachain blocks. They read `frame_system::Pallet::::block_number()` directly (17 sites in `pallet/src/`, 1 in `pallet-registry/src/lib.rs`), and the runtime constants derive from a 6s parachain block.

This is wrong: parachain block time is changing (6s -> 2s/3-cores, targeting AssetHub) and will change again. Anything denominated in parachain blocks silently rescales with it -- e.g. `48 * HOURS` becomes 16h of wall-clock once blocks are 2s.

Decision (per Robert): always use relay chain blocks for these durations, to stay independent of parachain block time.

Scope

Currently the bug is latent (6s == 6s) and bites the moment the parachain switches to 2s.

Affected config: `ChallengeTimeout`, `SettlementTimeout`, `RequestTimeout`, `DefaultCheckpointInterval`, `DefaultCheckpointGrace`, `DeregisterAnnouncementPeriod`, agreement durations/extensions, drive expiry.

Plan

1. Add `type BlockNumberProvider: BlockNumberProvider<BlockNumber = BlockNumberFor>` to both pallet `Config`s.
2. Replace all `frame_system::Pallet::::block_number()` reads with `T::BlockNumberProvider::current_block_number()`.
3. Runtimes: `type BlockNumberProvider = cumulus_pallet_parachain_system::RelaychainDataProvider`.
4. Mocks/tests: `type BlockNumberProvider = System`.
5. Recompute the time constants from a 6s relay block, independent of parachain block time.

Notes / open questions

• User-supplied durations (agreement `duration`, extensions) change meaning to relay blocks. Client/SDK/UI and payment-per-block math must interpret them consistently -- likely a follow-up.
• `RelaychainDataProvider` returns the relay parent number from validation data (monotonic, but delta between consecutive parachain blocks can be >1). Verify checkpoint window math (`calculate_window`) doesn't assume +1 per parachain block.

TODO

• check/align the design

Related: #113

[bkontur]

Heads-up: #125 (challenge flow overhaul) adds new block-denominated surface this migration must cover.

When switching to the relay BlockNumberProvider, also check/refactor:

1. MaxNonceAge — new block-duration config, not in the scope list. Add it and recompute from a 6s relay block.

2. The signed nonce is off-chain-sourced — CommitmentPayload.nonce is snapshotted by signers (JS demos use System.Number, provider-node/SDK pass a caller nonce) and recency-checked on-chain. If the on-chain check moves to relay blocks, every signer must snapshot the relay block too — provider-node + client SDK + JS demos, not just the pallet.

3. ReplicaSyncRecord.block — new stored block, paired with min_sync_interval in confirm_replica_sync. Migrate both together.

4. ⚠️ Real conflict — challenge deadlines are an on_finalize key. Challenges/NextChallengeIndex are keyed by deadline = created_at + ChallengeTimeout, and the slash sweep runs in on_finalize(n)/on_initialize(n), which are parachain-block driven. The deadline must stay a parachain block for the sweep to fire — but this plan wants ChallengeTimeout + created_at on relay blocks. Relay numbers don't map 1:1 to parachain blocks, so moving both breaks the timeout-slash sweep. ChallengeTimeout can't just follow the rest onto relay blocks while the deadline is a parachain-keyed on_finalize index — needs an explicit decision (carve it out as parachain-denominated, or redesign the sweep).

Items 1–3 are mechanical; item 4 is a design decision, not a find-and-replace.