Intruder payload processing and grep-match/grep-extract

Payload processing: an optional case rule (upper/lower) and an optional
encode rule (URL/Base64/Hex/HTML) applied to every payload line before
it's substituted into the request, cycled with 'c'/'e'. Case always
runs before encode - folding an already-encoded value would corrupt it
(e.g. uppercasing Base64 padding). Applied entirely client-side in
startIntrude() (payload_rules.go): a pure string transform with no
proxy-side state, so it needs no protocol changes and reuses the
Decoder's own urlEncodeAll.

Grep-match/grep-extract: two optional Go regexps, edited with 'm'/'v'
using the same modal edit-buffer pattern as the history list's '/'
search (enter validates-and-commits, esc reverts to the last-confirmed
pattern, an unparseable regexp is rejected with an error rather than
silently accepted). Evaluated server-side, in internal/ipc/server.go's
"intrude" handler, against each result's actual entry.ResponseRaw -
that's where the real response bytes already are, and it's how Burp's
own grep options work (matched against the real response, not a
client-refetched copy). Grep-match flags a result (new Match column);
grep-extract captures the first submatch, or the whole match if the
pattern has no capturing group (new Extract column). Both patterns are
compiled once before the attack starts and apply for that run only, not
retroactively if changed mid-attack.

All four new keys (c/e/m/v) are gated to normal mode, checked in the
view's outer key switch before ever reaching the template/payloads
vi-textareas - otherwise they'd be either untypeable letters or steal
keystrokes mid-edit. Same discipline as the Repeater tab keys.

internal/ipc: Request gained GrepMatch/GrepExtract string fields (for
"intrude"), IntrudeResultMsg gained GrepMatch bool/GrepExtract string,
and the client Intrude() helper takes the two pattern strings as new
trailing parameters.

Verified live in tmux against a running daemon and real httpbin.org
traffic: built a template with a §marked§ query param, payloads 1/2/3,
grep-match `"id": "2"` and grep-extract `"id": "([0-9]+)"`, ran the
attack and confirmed the Match column flagged only the payload=2 row
and Extract correctly pulled 1/2/3 from each response respectively;
cycled case/encode through all states; confirmed an invalid regexp
(`[abc`) is rejected with a visible error and esc correctly reverts to
the last-confirmed pattern instead of committing the invalid one.

(Also confirmed, incidentally: a batch of vi normal-mode two-key
commands like "gg"/"dd" sent as one multi-character tmux send-keys
argument doesn't reliably reach the app as separate keystrokes - a
tmux scripting artifact, not a bug in the vi-mode implementation, which
works correctly when each key is sent as its own event, as any real
keypress would be.)

go build/vet/gofmt/test/mod tidy all clean.

1 files changed, 32 insertions, 1 deletions

diff --git a/README.md b/README.md
index c91e455..67536c7 100644
--- a/README.md
+++ b/README.md
@@ -43,7 +43,11 @@ list of what's deliberately not implemented (and why), see
 - **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
-  as everything else, searchable the same way.
+  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
+  result's response with a regexp) are both configurable before starting
+  an attack - see [Intruder](#intruder) below.
 - **Match-and-replace**: header rewrite rules (add, remove, or modify)
   for requests and/or responses, applied live as traffic passes
   through. History still shows what was actually sent/received on each
@@ -218,6 +222,33 @@ closes the active one. All three only fire in normal mode, so they
 don't interfere with typing (`[`/`]` show up in JSON bodies constantly,
 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
+shortcuts, available from any pane:
+
+- `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
+  every payload, case first then encode, right before it's substituted
+  into the request - case-folding an already-encoded value would
+  corrupt it (e.g. uppercasing Base64 padding), so case always runs on
+  the original text first.
+- `m` / `v` edit **grep-match** / **grep-extract**, each a Go regexp
+  evaluated against every result's actual response bytes (same `enter`
+  confirms / `esc` cancels pattern as the history list's `/` search - an
+  invalid regexp is rejected with an error rather than silently
+  accepted). Grep-match flags a result (a `Match` column) if the pattern
+  is found anywhere in the response; grep-extract captures the first
+  submatch - or the whole match, if the pattern has no capturing group -
+  into an `Extract` column. Both are optional and independent; leave
+  either blank to skip that check.
+
+Both settings apply for the attack you're about to start - changing
+them mid-run doesn't retroactively re-evaluate requests already sent,
+matching Burp's own behavior.
+
 ### Match-and-replace rules
 
 Press `m` from the history view. Rules match request or response