history coverage: exact loadCoverageRatio==1 requirement makes 24h activity and Regions rates 'unknown' after many restarts #509

Problem

retainedHistoryCoverageStartLocked returns an unknown coverage start unless LoadCoverageRatio() is exactly 1. The startup "done" gate accepts 90%. When retention or eviction run while the background load is finishing, the ratio can end slightly below 1 and stays there until the next restart.

Observed on staging (2026-10-20, retentionHours 48, maxMemoryMB 1800) after a restart:

• /api/perf reported loadCoverageRatio: 0.9989, backgroundLoadComplete: true, backgroundLoadProgress: 100.
• /api/regions/history reported coverage.start: null for 10+ minutes and every Regions scope showed "Rate unavailable".
• Node activity24h (My Mesh) returned complete: false, coverageStart: null.

On 2026-10-15/17 the same code reached exactly 1 after a restart, so this is intermittent. It is pre-existing (it also applies to v0.2.5's node 24h activity) and is now much more visible through the Regions views.

Proposal

• Base coverage on what was actually loaded, without requiring an exact row-count match. Rows removed by retention or eviction during the load must not count as missing.
• Alternatively, recompute the ratio after the first eviction or retention tick.
• Add a test where retention removes rows during the background load and coverage still becomes known.
• Verify on staging across several restarts.