Body match-and-replace rules

Extends match-and-replace rules to request/response bodies, not just
headers. A body rule materializes the body into memory (bounded by
the same maxCaptureBytes cap as history capture) instead of streaming
it straight through - the opposite of the normal path, so it's only
paid when a body rule is actually configured. A body over the cap
passes through byte-exact and unmodified rather than being partially
rewritten.

Response Content-Length is recomputed explicitly when a rule changes
body length: unlike http.Request.Write, http.ResponseWriter doesn't
derive it from resp.ContentLength on its own, so a stale header would
otherwise corrupt response framing for the client.

The history audit trail still shows the original, pre-rule bytes on
both legs; only the wire traffic reflects the rewrite. Verified live
against a real daemon: origin receives the rewritten request body,
client receives the rewritten response body with correct
Content-Length, and history keeps the unmodified bytes.

Adds a Part selector (header/body) to the Rules add/edit form and
table in the TUI.

1 files changed, 11 insertions, 9 deletions

diff --git a/PLAN.md b/PLAN.md
index fe55cf8..8c86d18 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -51,15 +51,17 @@ hudsucker) - same problem, worth studying even though this build is Go.
   boundaries, not just per-connection ones).
 - CA install UX per OS (Linux/macOS/Windows trust stores)
 - Whether WebSocket interception is v1 or a later addition
-- Step 6 match-and-replace shipped headers-only. Body rules are a
-  separate, harder problem: request-body capture currently relies on
-  streaming the body straight from the client connection to the
-  upstream write (that's what makes it exact, byte for byte); a body
-  rule needs to materialize, transform, and re-send it instead, which
-  means deciding what "exact" even means for a rule-modified request
-  before touching that path again. Also still single-line-text-field
-  limited in the TUI (bubbles/textinput can't hold a literal CRLF), so
-  even with header rules, injecting a brand-new header line via the
+- Step 6 match-and-replace now covers headers and bodies. Body rules
+  materialize the body into memory (bounded by the same
+  maxCaptureBytes cap as history capture) rather than streaming it
+  straight through - the opposite of the normal path, so it's only
+  paid when a body rule is actually configured. A body over the cap is
+  passed through byte-exact and unmodified rather than partially
+  rewritten. Response Content-Length is recomputed explicitly when a
+  rule changes body length, since http.ResponseWriter (unlike
+  http.Request.Write) doesn't derive it automatically. Still
+  single-line-text-field limited in the TUI (bubbles/textinput can't
+  hold a literal CRLF), so injecting a brand-new header line via the
   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.