Fourth plugin: bpscanner, a Backslash Powered Scanner-style detector

- Phase 1 plugin ecosystem complete

The last of the four "cheap IPC win" plugins identified in the
original research pass. Different mechanism from the other three,
deliberately: where paramminer finds parameters that shouldn't exist,
bpscanner tests parameters that already do, asking a more general
question than a signature-based scanner does - does the backend treat
syntactically-significant characters ('"\<>(){}$;|&, covering SQL
quoting, HTML/JS, shell metacharacters, and template syntax at once)
differently than an equal-length string of inert filler? That question
doesn't need to know what the backend is built on, the whole appeal of
the real tool this borrows its name and idea from.

For each existing query parameter, sends two same-length replacement
values wrapped in a stable marker - one filler, one special-character
- and checks whether the marker itself came back intact, not just
whether the response looks different overall. An endpoint that never
reflects the parameter at all naturally produces "both intact: false,"
which correctly isn't a finding - the marker-reflection design avoids
false-positiving on the common case of a parameter that's read but
never echoed.

Verified live against a deliberately realistic scenario: an origin
with one endpoint that strips a few special characters before
reflecting a parameter (a naive-sanitizer/WAF-like pattern) and one
that reflects verbatim (the control case) - the sanitizing endpoint
was correctly tagged with the exact differential
(control_marker_intact: true, special_marker_intact: false), the
verbatim endpoint correctly left alone.

This closes Phase 1: every plugin identified as a "cheap IPC win" - no
new protocol capability needed beyond tag_entry itself - is now real,
working, and live-verified (authcheck, paramminer, jslibscan,
bpscanner).

1 files changed, 46 insertions, 4 deletions

diff --git a/PLAN.md b/PLAN.md
index 014c902..ed55d0c 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -1018,7 +1018,49 @@ was real: an entry captured *before* the fix (same file, same content,
 requested moments earlier against the buggy binary) sat right next to
 the correctly-tagged one in the history list, untagged.
 
-Next: the remaining Phase 1 plugin (Backslash Powered Scanner - no new
-protocol capability needed, same pattern the three shipped plugins
-already validate), then the live-RPC protocol addition for JWT
-Editor/SAML Raider.
+### Fourth plugin shipped: `plugins/bpscanner` - Phase 1 complete
+
+A Backslash Powered Scanner-style generic injection detector, and the
+last of the four "cheap IPC win" plugins identified in the original
+research pass. Different mechanism from the other three, deliberately:
+where paramminer finds parameters that shouldn't exist, bpscanner tests
+parameters that already do, by asking a more general question than a
+signature-based scanner does - does the backend treat
+syntactically-significant characters (`'"\<>(){}$;|&`, covering SQL
+quoting, HTML/JS, shell metacharacters, and template syntax at once)
+differently than an equal-length string of inert filler? That question
+doesn't need to know what the backend is built on, which is the whole
+appeal of the real tool this borrows its name and idea from.
+
+For each existing query parameter, sends two same-length replacement
+values wrapped in a stable marker (`zzMARKzz`) - one filler, one
+special-character - and checks not just whether the response *looks*
+different (length/status diffing, what the other three probing-based
+plugins use) but whether the marker itself came back *intact*: if the
+filler value survives unmodified but the special-character one doesn't
+(stripped, escaped, or altered), or the two produce different status
+codes outright, something downstream is interpreting those characters
+rather than treating the parameter as inert data. An endpoint that
+doesn't reflect input at all naturally produces "both intact: false,"
+which correctly isn't a finding - the marker-reflection design avoids
+false-positiving on the (very common) case of a parameter that's read
+but never echoed anywhere.
+
+Verified live end to end against a deliberately realistic scenario: a
+real origin with one endpoint that reflects a query parameter after
+stripping a few special characters (a naive-sanitizer/WAF-like pattern,
+a genuinely common real-world shape) and one that reflects verbatim
+with no stripping (the control case) - the sanitizing endpoint was
+correctly tagged (`control_marker_intact: true`,
+`special_marker_intact: false`, exactly the differential the plugin is
+built to catch), the verbatim endpoint was correctly left alone,
+confirmed via the JSON tag data in the TUI.
+
+This closes Phase 1: every plugin identified as a "cheap IPC win" - no
+new protocol capability needed beyond `tag_entry` itself - is now real,
+working, and live-verified (authcheck, paramminer, jslibscan,
+bpscanner). Next: the live-RPC protocol addition for JWT Editor/SAML
+Raider - a genuinely different shape of plugin (interactive, on-demand
+from the TUI, not just subscribe-and-tag) - or the bigger separate-
+project items (active scanning, Collaborator/OAST, a crawler) if that's
+the higher priority instead.