fix(detector): flag chr-concat string construction as obfuscated dispatch

[SinatrasC]

Summary

Targets red #17 under "Direction — Obfuscated exec / dynamic execution",
submitted via the Flywheel-proxied path with no participant KG API key
(the public-participant flow described on the campaign root). Live
kernelguard==0.2.2 classifies it valid:

def custom_kernel(data):
    op = chr(99) + chr(108) + chr(111) + chr(110) + chr(101)
    return getattr(data, op)()

The string "clone" is built character-by-character at runtime, then
handed to getattr to execute the underlying data.clone(). There is
no literal eval / exec / compile / __import__ anywhere in the
source, so detect_dynamic_execution's existing Call-walking pass
doesn't fire.

Approach

After the existing Call-walking pass, walk all BinOp nodes once. For
each Add chain, recursively count chr() call leaves:

• BinOp(Add, lhs, rhs) → count(lhs) + count(rhs)
• Call(Name('chr'), ...) → 1
• anything else → -1 (disqualifies the whole chain)

If the chain has ≥ 3 chr leaves, emit an OBFUSCATED_EXEC match
with evidence noting the leaf count. Below 3, or any non-chr / non-Add
node mixed in, the chain is silently ignored.

Why this rule is safe

• Three-or-more chr() calls chained with + essentially never appear
  in legitimate compute kernels. The 20 nvfp4 false-positive cases are
  real production GEMM/GEMV implementations — none of them use chr().
• The threshold of 3 leaves and the strict "all leaves must be chr()"
  rule mean two-character constructions, mixed-literal strings ("abc" + chr(10)), and incidental string assembly with format strings all stay
  unflagged.
• The existing OBFUSCATED_EXEC Call-walking pass for lzma/b64/zlib
  payloads is unaffected — both passes can match independently and
  contribute to a single result.

KernelGuard-Red-Submission: 17

Test plan

• chr_concat_clone (red fix(detector): add IS_NONE_SENTINEL_REPLAY for RED #30 #17) → OBFUSCATED_EXEC, should_filter=True
• chr_concat_exec_call (sibling shape: builds "exec", dispatches via __builtins__) → flagged
• two_chr_only_not_flagged → stays valid (only 2 chr leaves, below threshold)
• plain_kernel → stays valid
• plain_string_concat_legit (string literals, no chr) → stays valid
• classic_obfuscated_exec (lzma + base64 + exec) → still flagged via the existing Call-walking pass

[github-actions]

KernelGuard Blue Evaluation

• Evaluation job: 25
• Blue submission: 15
• 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/25215714212

[SinatrasC]

Thanks for the KernelGuard Flywheel Campaign contribution. We are not selecting this PR for merge because it is too narrow or not aligned with the current consolidated rule-family surface.