[Bug] Usage Policy classifier stuck in blocked state for legitimate kernel security work

Bug Description
Summary: Legitimate Linux kernel security/debugging work is being repeatedly blocked as a Usage Policy violation, including follow-up messages as innocuous as "Hi".
Context: I'm a Linux kernel engineer doing defensive security research — fuzzing kernel networking subsystems with syzkaller/BRF and writing C reproducers to confirm and fix crashes (e.g. a divide-by-zero I'm trying to reproduce so it can be patched and upstreamed). This is standard kernel debugging: a reproducer is the tool used to fix the bug, not to attack anything.
The problem: Requests like "create the file I can compile/run on the VM to trigger the bug" and "help find a reproducer for the divide-by-zero" are being rejected with "appears to violate our Usage Policy." Worse, once a session gets flagged, every subsequent message is blocked — including plain "Hi", "What's going on?", and "You okay?". The session becomes unusable and doesn't recover; only starting a brand-new session helps. This strongly suggests the classifier is weighting accumulated session context and getting stuck in a blocked state.
Why it's a false positive: The work is defensive kernel debugging (reproduce → fix → upstream). The trigger appears to be vocabulary overlap — "trigger the bug," "reproducer," "exploit a crash" — between fixing kernel bugs and attacking them, which are lexically near-identical but opposite in intent.
Impact: Blocks normal professional kernel development. Having benign messages like "Hi" rejected because of prior session context is especially disruptive.
Request IDs from the blocked turns:

req_011CbMvL4CzgzKmCJX4Bkk34
req_011CbMvTRtvUVb8SMWdkftkF
req_011CbMvVnf9NFGjxPmm6tuex
req_011CbMvcBHLfUV7DPTWdgMjS
req_011CbMvhgQggamokfpGmj8Dn
req_011CbMj5qpwVk2R86fhfPMGy (earlier turn, same session)

Environment Info

• Platform: linux
• Terminal: xterm-256color
• Version: 2.1.149
• Feedback ID: 272d13cc-8eaf-4c29-8096-2a6991ad44d9