fix: honor rotated cnight cache config

[gilescope]

Motivation

• The sliding-window cNIGHT observation cache previously captured cNIGHT query parameters at startup and continued to serve cached observations even after runtime/governance rotated the mapping validator address, auth token name, or cNIGHT asset identifier, creating stale inherent data and potential consensus disagreements.

Description

• Store the cache's active cNIGHT parameters in an Arc<RwLock<CNightAddresses>> and record the CNightAddresses used for each same-tip memoized result so cached data is tied to the originating runtime config.
• Add sync_runtime_config to compare the per-call runtime config to the cache's active config and, on mismatch, invalidate the in-memory window, clear the same-tip memoized result, and reset the cache anchor so the call falls back to the DB-backed source.
• Make background refreshes snapshot the currently active runtime config and discard any in-flight refresh result if the active runtime config has changed by the time the refresh would commit, so refreshes do not populate the window with stale parameters.
• Make the same-tip reuse path compare the requested config against the stored config and only reuse cached results when configs match, while preserving DB fallback behavior for out-of-window queries.
• Add a focused unit test that proves a rotated runtime cNIGHT config invalidates the window and clears the memoized result, and add a changes/ change file documenting the security fix.

Testing

• Ran cargo fmt --check and it succeeded.
• Ran cargo check -p midnight-primitives-mainchain-follower and it succeeded.
• Ran the new targeted test with cargo test -p midnight-primitives-mainchain-follower sync_runtime_config_invalidates_window_for_rotated_cnight_config and it passed.
• Verified cargo test for the modified crate (unit tests) completed with the new test passing.

---

Codex Task

[justinfrevert]

These sort of comparisons could be implemented in Eq or PartialEq.