fix(detector): detect threadlocal replay

[prasannakotyal]

Summary

Targets KG red #172, where custom_kernel stores the first input-derived output on a module-level threading.local() object, then returns that same thread-local attribute from an input-independent fast path.

This adds a narrow THREADLOCAL_REPLAY detector. It requires:

• a module-level threading.local() state object
• an entrypoint assignment to one of that object's attributes from an input-derived call
• an input-independent guard over that same thread-local attribute, including hasattr(...)
• a call-free replay body returning the same thread-local attribute

Threading events, locks, generic object attributes, and clean local tracing stay out of scope.

KernelGuard-Red-Submission: 172

Local verification

• red_55_threadlocal_replay -> THREADLOCAL_REPLAY, should_filter=True
• red_166_threading_event_replay stayed valid
• red_403_thread_lock_flag_replay stayed valid
• red_18_simple_namespace_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: 90
• Blue submission: 63
• 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/25243854797

[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.