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.

0 files changed, 0 insertions, 0 deletions