Intruder: Battering ram, Pitchfork, and Cluster bomb attack modes

Generalizes Intrude beyond Sniper to all four of Burp's attack modes
(proxy.AttackMode). Sniper and Battering ram only ever need one shared
payload set; Pitchfork and Cluster bomb are inherently per-position, so
they take one payload set per §marked§ position instead.

Request-set generation (intrudeValues) is pure and side-effect free,
so the total request count is validated against the existing 1000
cap before anything is dispatched - Cluster bomb's product is checked
incrementally, one payload set at a time, so a pathological product
bails out before ever trying to enumerate it. This also makes the
combinatorics unit-testable without a live target.

IntrudeResultMsg now reports Values (one substitution per marked
position, in order) instead of a single Position/Payload pair, since
three of the four modes touch multiple positions per request.

TUI: `a` cycles the attack mode. Pitchfork/Cluster bomb reuse the
existing single Payloads pane rather than a new multi-widget editor -
sets are separated by a `---` delimiter line, in position order.

Verified live against a real daemon: all four modes produce the
expected substitution values and request counts, and pitchfork
correctly rejects a payload-set count that doesn't match the
template's marked positions.

1 files changed, 13 insertions, 7 deletions

diff --git a/PLAN.md b/PLAN.md
index 8c86d18..87c01cf 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -65,13 +65,19 @@ hudsucker) - same problem, worth studying even though this build is Go.
   form isn't possible yet - only rewriting/removing existing ones. The
   underlying engine (rules.ApplyHeaders) already supports arbitrary
   text-block edits; it's specifically the form UI that's constrained.
-- Step 7 (Intruder-equivalent) shipped Sniper only: one payload set,
-  one §marked§ position fuzzed at a time, every other marked position
-  held at its base value - the mode that covers most real Intruder
-  usage. Battering ram / pitchfork / cluster bomb aren't implemented.
-  Sequential sending only (no concurrency), capped at 1000 generated
-  requests as a fixed safety limit against an accidental huge wordlist
-  combined with several positions. Reuses the Repeater send primitive
+- Step 7 (Intruder-equivalent) now covers all four of Burp's attack
+  modes (proxy.AttackMode: Sniper, BatteringRam, Pitchfork,
+  ClusterBomb). Sniper and BatteringRam only ever need one shared
+  payload set; Pitchfork and ClusterBomb are inherently per-position,
+  so they need one set per §marked§ position - the request-generation
+  logic (intrudeValues) is pure and side-effect free specifically so
+  the request count (positions × payloads for Sniper, a product for
+  ClusterBomb) can be validated against the 1000-request cap before
+  anything is dispatched, and so it's unit-testable without a live
+  target. The TUI reuses the single Payloads pane for per-position sets
+  too, split by a `---` delimiter line, rather than adding a
+  multi-widget payload-set editor. Sequential sending only (no
+  concurrency). Reuses the Repeater send primitive
   (proxy.Server.sendRaw) directly - an attack is just that primitive
   run in a loop with generated bytes - and results land in the same
   history table tagged source="intruder", same as Repeater's