memHierarchy: preserve same-address request order under MSHR pressure

[jake-ke]

Fixes #2710 .

Problem

Cache::clockTick scans the per-cycle event buffer front-to-back, retrying any event it cannot accept. When a request to a line is rejected mid-scan (e.g. MSHR full) and a response later in the same scan frees the resource, a later same-address request can be accepted ahead of the earlier one — inverting two same-address requests from a single source. For back-to-back writes this silently drops an update: the older request lands last and overwrites the newer one, corrupting memory with no error raised. Most easily hit under coherence_protocol=none with a finite MSHR, but the reorder is protocol-independent.

Fix

Track addresses whose request was rejected this cycle in rejectedAddrsThisCycle_ and hold every later same-address request for the rest of that cycle's scan. On the next cycle the event buffer's FIFO order lets the earlier request claim the freed resource first. Responses are exempt so MSHR-draining events (GetXResp, WriteResp, AckPut, NACK, …) always flow and forward progress is preserved. Changes are confined to cacheController.{cc,h} (+22/−0).

Testing

• Compiles and links against sst-core 15.0.0.
• The reorder is a narrow within-cycle timing window and does not reliably reproduce with stock synthetic traffic generators (data-independent payloads, and the required same-cycle rejection→free→same-address sequence doesn't arise consistently), so no deterministic unit test is included. The defect is established by code analysis (see #NNNN); it was observed under a data-dependent workload.
• Behavioral impact is limited to deferring a later same-address request by one cycle only when an earlier same-address request was rejected in the same scan; the common (uncontended) path is unchanged, and responses are never held.

Happy to add a directed regression test if a reviewer can suggest a traffic pattern that reliably hits the window.

[sst-autotester]

Status Flag 'Pre-Test Inspection' - - This Pull Request Requires Inspection... The code must be inspected by a member of the Team before Testing/Merging
NO INSPECTION HAS BEEN PERFORMED ON THIS PULL REQUEST! - This PR must be inspected by setting label 'AT: PRE-TEST INSPECTED'.