Refresh expired mining candidates on request

[a-shannon]

Reopens #2443 against v6.0.7. GitHub closed the original PR automatically when its v6.0.4 base branch was deleted.

Problem

Candidate expiry is checked while handling ChangedMempool, but a mempool change can arrive before blockCandidateGenerationInterval elapses. In that case the reader is updated without regenerating. If the pool then stays unchanged, later non-forced mining requests can keep returning the expired candidate because the cache-hit path does not check its age.

This can leave transactions already present in the node's mempool out of successive mining jobs beyond the configured refresh interval.

Fix

• Require a compatible cached candidate to still be unexpired before serving it.
• Regenerate through the existing slow path on the first non-forced poll after expiry.
• Preserve solved-block handling and the existing previous-candidate fallback.
• Add an actor regression for the change-before-expiry event ordering.
• Keep the existing forced-cache test independent of expiration.

Validation

• CandidateGeneratorSpec: 20/20 passed.
• MiningApiRouteSpec: 10/10 passed.
• ErgoMinerSpec: 5/5 passed.
• git diff --check passed on b8eb8f402.
• Independent review of the v6.0.7 replay found no blocker or duplicate implementation.

Scope

This patch does not change mempool ordering or candidate transaction-selection policy. It complements the regeneration work in #1363, #1412, #2164, and #2231 by enforcing candidate lifetime when a later non-forced request reads the cache.