fix(detector): detect heapq replay

[prasannakotyal]

Summary

Targets KG red #171, where custom_kernel pushes an input-derived result into a module-level heap through heapq.heappush, then returns heap[0] from an input-independent fast path on later calls.

This adds a narrow HEAPQ_REPLAY detector. It requires:

• a module-level list used as heap state
• an entrypoint mutation through heapq.heappush, heapq.heapreplace, or heapq.heappushpop
• the pushed/replaced heap payload to reference an input parameter
• an input-independent replay guard over the same heap state
• a call-free replay body returning a subscript rooted on that heap

Other queue-like state and marker-only heap usage stay out of scope.

KernelGuard-Red-Submission: 171

Local verification

• red_54_heapq_replay -> HEAPQ_REPLAY, should_filter=True
• red_128_priorityqueue_replay stayed valid
• red_124_deque_tuple_replay stayed valid
• red_445_heap_marker_replay stayed valid
• clean fixtures in eval_blue_patch.py stayed valid
• uv run python -m py_compile kernelguard.py

[github-actions]

KernelGuard Blue Evaluation

• Evaluation job: 67
• Blue submission: 47
• Result: passed
• Target red submission caught: True
• Validation suite: TP 20/20, FP 20/20
• Surgicalness score: 1.0
• Workflow run: https://github.com/SinatrasC/kernelguard/actions/runs/25238323156

[SinatrasC]

Thanks for the KernelGuard Flywheel Campaign contribution. We are not merging this narrow variant separately because the consolidated rule-family implementation in #273 is the merge path for this detector area.