Multiple concurrent Repeater tabs

Repeater previously had one shared request/response buffer - sending a
new entry to Repeater silently overwrote whatever was already open,
even mid-edit. Replaced the singular reqArea/respView/repeaterScheme/
etc. model fields with a []*repeaterTab slice plus an active index;
'r' now opens a new tab and switches to it, existing tabs stay put.

New keys, all gated to normal mode so they stay inert while typing
(]/[ show up in JSON bodies constantly, and ctrl+w is the textarea's
own delete-word-backward that must still work mid-edit):
  ]     next tab
  [     previous tab
  ctrl+w  close the active tab (falls back to a neighbor, or to the
          history list if it was the last one)

Async send results now carry the tab index they belong to, so a slow
send whose response lands after the user has switched tabs (or closed
one) updates the right tab rather than whichever happens to be active
when the result arrives; the status line and response pane only reflect
it live if that tab is still the one being viewed.

Verified live in tmux against a running daemon: opened two tabs from
different history entries, confirmed independent buffers, sent from a
background tab while another was active and confirmed the result routed
to the correct (non-visible) tab, switched with ]/[, closed with ctrl+w
down to zero tabs (falls back to the history list), and confirmed [, ],
and ctrl+w are all correctly inert in insert mode (typed "[a]" literally,
ctrl+w did textarea's word-delete instead of closing the tab).

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

1 files changed, 10 insertions, 1 deletions

diff --git a/README.md b/README.md
index 9bc683e..c91e455 100644
--- a/README.md
+++ b/README.md
@@ -36,7 +36,10 @@ list of what's deliberately not implemented (and why), see
   column filters like `host:example.com`, and `AND`/`OR`/`NOT`.
 - **Repeater**: edit and resend a raw request. What you type is what
   goes on the wire - no normalization, no auto-fixed `Content-Length`,
-  no "helpful" reformatting. That's the point of a Repeater.
+  no "helpful" reformatting. That's the point of a Repeater. Multiple
+  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
@@ -209,6 +212,12 @@ switches panes. In Intruder's template pane specifically, `ctrl+g`
 inserts a `§` marker at the cursor if typing the character directly
 isn't convenient on your keyboard/terminal.
 
+Repeater supports multiple concurrent tabs - each open request/response
+pair is independent. `]`/`[` switch to the next/previous tab, `ctrl+w`
+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).
+
 ### Match-and-replace rules
 
 Press `m` from the history view. Rules match request or response