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, 22 insertions, 7 deletions

diff --git a/README.md b/README.md
index ea2a885..4d424e6 100644
--- a/README.md
+++ b/README.md
@@ -40,9 +40,10 @@ list of what's deliberately not implemented (and why), see
   tabs: sending an entry to Repeater opens a new tab rather than
   replacing whatever's already there, so you can iterate on several
   requests side by side.
-- **Intruder** (Sniper only): mark positions in a request template
-  with `§markers§`, supply a payload list, fuzz one position at a time
-  against a shared payload set. Results land in the same history table
+- **Intruder**: mark positions in a request template with
+  `§markers§`, supply payloads, and fuzz them with Sniper, Battering
+  ram, Pitchfork, or Cluster bomb - Burp's own four attack modes.
+  Results land in the same history table
   as everything else, searchable the same way. Payload processing
   (optional case and encode rules, applied to every payload before it's
   sent) and grep-match/grep-extract (flag or pull text out of each
@@ -368,10 +369,24 @@ and `ctrl+w` is the editor's own delete-word-backward while composing).
 
 ### Intruder
 
-Beyond marking `§positions§` and supplying payloads, two more things are
-configurable before `ctrl+r` starts the attack - both normal-mode-only
+Beyond marking `§positions§` and supplying payloads, three more things
+are configurable before `ctrl+r` starts the attack - all normal-mode-only
 shortcuts, available from any pane:
 
+- `a` cycles the **attack mode**: Sniper, Battering ram, Pitchfork,
+  Cluster bomb - Burp's own four, same semantics. Sniper fuzzes one
+  marked position at a time through a single shared payload set, every
+  other position held at its base value. Battering ram sends the same
+  payload, from that same single set, into every marked position at
+  once. Pitchfork and Cluster bomb are inherently per-position - that's
+  their whole point - so they need one payload set per marked position
+  instead of one shared set: put them in the same Payloads pane,
+  separated by a line containing exactly `---`, in position order.
+  Pitchfork walks all sets in lockstep, one request per index, stopping
+  at the shortest set's length. Cluster bomb tries every combination
+  (the last position cycles fastest), so its request count is the
+  product of every set's length - capped at 1000 requests like every
+  other mode, checked before anything is sent.
 - `c` / `e` cycle **payload processing**: an optional case rule
   (off/upper/lower) and an optional encode rule (off/URL/Base64/Hex/
   HTML), shown in the status line above the results table. Applied to
@@ -518,8 +533,8 @@ messages for what was checked and how.
 Deliberate scope decisions, not oversights - see `PLAN.md` for the
 reasoning behind each:
 
-- Intruder: Sniper attack only (no battering ram / pitchfork / cluster
-  bomb), sequential sending, capped at 1000 requests per attack
+- Intruder: sequential sending only (no concurrent workers), capped at
+  1000 requests per attack across all four modes
 - `mitmuxd -install-ca` prints per-OS trust-store install steps; it
   never runs them for you (see Quick start above for why)
 - No WebSocket interception