fix(control-panel): make cycle monitoring independent of monitored canisters

[MRmarioruci]

Change

The control panel is not a controller of the stations it funds — the station resets its own controllers to [upgrader, NNS root] during init (services/system.rs:359-363) — so it reads each balance by calling that station's http_request and parsing a Prometheus metric. Both the timing and the value of that response therefore come from the monitored canister.

The monitoring round is coupled to both. canfund awaits every registered canister inside one join_all while holding the process lock (canfund-0.8.3/src/manager/mod.rs:208-217, :411), so the round's completion depends on every canister replying; and the reported value feeds a consumption-rate calculation whose multiplication is not saturating (manager/record.rs:49-60) while the workspace builds with overflow-checks = true.

Two layers around the fetcher remove both dependencies:

• BoundedCyclesFetcher rejects readings above u128::MAX / 1_000_000_000, the point past which that multiplication can leave u128. The bound is derived, not chosen: at or below it the product fits for any pair of accepted readings.
• CachedCyclesFetcher answers from a local cache and never awaits a canister inside the round; the call happens in a spawned task that updates the cache when it completes. The round takes and releases the lock regardless of how any canister behaves.

Supporting details:

• A refresh is not started while one is already in flight for the same canister, so an unresponsive canister costs one open call context rather than one per round.
• Readings older than three days stop being used. The round is daily, so this tolerates one missed refresh.
• Rejections and stale entries surface as MetricsHttpRequestFailed, which canfund already records per canister via set_funding_failure without aborting the round.
• Adds async-trait to the control panel (already a workspace dependency).

Tests

Eight cases in services::canister::bounded_cycles_fetcher_tests, covering the bound (plausible value, exactly at the bound, u128::MAX rejected, and a property test so the constant cannot drift out of correctness) and the cache (no reading yet, fresh reading served, expiry boundary, no second refresh while one is in flight).

cargo test -p control-panel --lib passes (215). Clippy and cargo fmt clean.

Trade-offs worth reviewing

Cold start. With no cached reading a canister is skipped for one round and funded from the next. Stations are funded at deploy time, so this is a day's delay on an already-funded canister.

Funding acts on data up to a day old. It already did, since the previous round's reading informed the same decision, but it is now explicit rather than incidental.

An unresponsive canister holds one open call context until it replies or is stopped, and its own monitoring slot degrades rather than the fleet's.

Note on upstream

canfund 0.8.5 changes neither behaviour: set_cycles is byte-identical and its fetcher uses Call::unbounded_wait. It also requires ic-cdk ^0.19 against this repo's 0.17.1, so adopting it is a two-major-version toolchain migration rather than a dependency bump. Handling this here avoids that.