feat(detection): add content_localization_service tag-block benchmark fixture

[Rahul-s-007]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update

Related issue: N/A — depends on #48 (the detector this fixture exercises); see #42 for full context.

What changed?
Adds content_localization_service.py, a new malicious MCP server fixture demonstrating Tag Block "ASCII smuggling" end-to-end (the existing mcp_connector.py fixture only covers the bidi-override variant). Registered in source_codes_registry.yaml and mcp_servers_registry.json, plus task 304 in tasks.json, following README.md's "Part 3: Enriching the Benchmark" process.

Fixes a review finding: the canary/encoder previously lived in a separate payload.py, imported by both the fixture and its tests. Since get_source_code reads exactly one file per server, a reasoning-agent source review of this fixture would only ever see a dangling from payload import ... with no way to fetch it — unlike all 25 sibling fixtures, which expose their full logic in the one registered file. Folded back inline, matching mcp_connector.py's own self-contained precedent.

Also removes the risk_level registry field from this fixture's entry and the README.md template (same finding as on the detector PR, carried through to this fixture's own registration).

Why?
Full context in #42/#48. This PR only lands meaningfully once #48 (the detector) is in, since nothing currently exercises this fixture without it.

How did you test it?
No mcp package in this environment (consistent with this session's policy of not installing heavy/paid-API-adjacent dependencies), so no live benchmark run. Instead: syntax-checked the fixture file; validated all touched JSON/YAML (source_codes_registry.yaml, mcp_servers_registry.json, tasks.json) parse correctly and stay internally consistent (total_servers count matches actual entries, task 304 is unique); confirmed risk_level and all payload.py references are fully gone; and verified the fixture's pure encode/decode logic standalone (no mcp dependency needed for that part) — the visible text plus a hidden Tag-Block payload round-trips correctly and is detectable by the regex the detector in #48 uses.

Potential risks
Low. Pure additions (new file + registry entries + one task) — no existing entries modified except the risk_level removal and the payload.py inlining, both narrowly scoped to this one fixture.

[pengyuzhang]

Blocking: the fixture self-labels its attack, leaking ground truth to the detector

content_localization_service.py names its own technique in three places that are shipped verbatim to the system under test:

• line 16, _CANARY
• line 20, docstring: "…(ASCII smuggling)"
• lines 42-43, comment: "Hidden ASCII smuggling payload appended via Unicode Tag Block characters / invisible to humans, fully readable to an LLM"

get_source_code (source_code_analyzer_server.py:42) returns the file raw, and adr_baseline.py:807 instructs the reasoning stage to call that tool on the servers in the trajectory. So on main_detector.py --detector adr, the escalated stage reads a comment that names the technique and scores task 304 a true positive without doing any detection reasoning — inflating recall.

This also contradicts two existing contracts: the "No pre-analysis or cheating metadata" note at source_code_analyzer_server.py:6, and the "no MALICIOUS labels" convention at Detection/README.md:494 that this same PR edits. Every other fixture in mcp_servers_1 respects it — memory_manager/memory_manager.py hides the payload behind innocuous comments and only reveals it in returned data ("sleeper_agent_activated": True). Grepping malicious|hidden|exfiltrat|smuggl|payload|covert across the other 25 fixtures returns zero hits.

Suggest renaming _CANARY to something domain-plausible and rewriting the docstring/comments to read like ordinary localization code.

For what it's worth, the mechanics are sound: all canary chars encode to valid Unicode Tag Block code points (U+E0020–U+E007F), total_servers 133→134 matches the actual key count, the registry path/command/args conventions match every other local server, the YAML entry style matches the other 116 entries, task_id: 304 is unique and formats correctly under f"task_{id:03d}", and dropping risk_level from the README example is right (no loader reads it). It's the comments around the fixture that break the benchmark, not the fixture itself.

[pengyuzhang]

Task 304 has no recorded trajectory, so the fixture is inert as shipped

Detection/benchmark/adr_bench_20251017_151604.jsonl contains exactly 303 task records (manifest "task_count": 303, last id task_303), and the documented detector command runs against that directory. main_detector.py enumerates task_* dirs and only scores tasks that have one, so task 304 is silently never analyzed — the new fixture contributes nothing to any metric until the benchmark is re-run and re-packed.

Secondary effect: the manifest embeds a full 303-task snapshot of tasks.json, so an inflate now produces a tasks.json that disagrees with the repo's 304-task file, while the detector loads ground truth from Path("tasks.json") in CWD.

Worth either shipping a recorded conversation for task 304 or calling this out explicitly in the PR description.

[pengyuzhang]

docs/REPRODUCIBILITY.md is now factually wrong

That doc exists to explain the 303-vs-302 delta against the paper. Line 17's header and line 19 ("ships 303 tasks (261 benign, 42 malicious)") no longer hold — tasks.json is now 304 / 261 / 43.

Line 21's claim that the delta is "one additional benign task … included in tasks.json and the packed benchmark JSONL" is doubly wrong after this PR: the new task is malicious, and it is not in the packed JSONL. Lines 86 and 155 still say 303.

Anyone reconciling against paper Table 2 gets the wrong recall denominator. Either update these or note explicitly that task 304 sits outside the paper evaluation set.

[pengyuzhang]

Stale counts introduced by this PR

Detection/README.md:

• line 61 — "303 scenarios (261 benign, 42 malicious)" → 304 / 261 / 43
• lines 62, 136, 159, 593, 624 — "133 servers" → 134; line 136's breakdown "102 local" → 103
• line 121 — "Vulnerable tools (25 servers)" → 26
• lines 165, 591, 599, 623 — "303 tasks" → 304
• line 312 — repeats the "one additional benign task" framing

README.md: line 13 "133 MCP servers" and line 24 "133 MCP servers, 303 benchmark tasks" → 134 / 304.

The Expected Performance checklist at line 624 is the one that actually bites: it tells the reader to verify "102 local", which mismatches total_servers: 134 in mcp_servers_registry.json.