Bulk export as HAR ('E' from the history list)

Single-entry export (previous commit) covers "attach this one to a
report"; this covers the other common need - getting a batch of
captured traffic into another tool. HAR 1.2 was chosen specifically for
interop: Chrome/Firefox DevTools, Burp, Postman, and others can all
import it, which a mitmux-specific format couldn't do.

cmd/mitmux/har.go: harEntryFromDetail parses one entry's raw request/
response bytes into HAR's structured fields (method, url, httpVersion,
headers, query string, status, body) via the same net/http parsing the
proxy's own capture path and prettyResponse already use elsewhere in
this codebase - reused, not reimplemented. A binary body is base64-
encoded (HAR's "encoding" field) instead of passed through as a JSON
string: encoding/json replaces invalid UTF-8 with U+FFFD by default,
which would silently corrupt exactly the bodies (images, protobufs,
...) where byte-exactness matters. harDocFrom builds the full document
from a batch of entries, skipping (not failing on) any that fail to
parse - one malformed capture, e.g. a deliberately broken Repeater
request, shouldn't block exporting everything else.

'E' from the history list exports the current view - the visible,
filtered set if a search is active, everything otherwise, same
"respects the active filter" behavior 'x' delete already has and
explicitly the opposite of 'X' clear-all, which always targets
everything regardless of filter. Reuses the same modal path-prompt
state as single-entry export (exportEditing/exportInput), discriminated
by a new exportBulk bool so both share one text-input widget and
key-handling pattern rather than duplicating it. Since the list only
ever holds Summary metadata (no raw bytes), exporting has to fetch each
entry's full detail first - exportHAR does this as a sequence of Get
calls inside a single tea.Cmd, which runs in bubbletea's own command
goroutine, so the UI stays responsive through what's effectively a
blocking round trip per entry. A failed fetch is skipped the same way a
failed parse is; the status line reports the total skipped either way,
not just entries written, so a partial export is visible rather than
silently different from what was expected.

Verified live in tmux against a running daemon: exported 3 real
captured entries (including a binary PNG response) to a HAR file,
validated the output is well-formed JSON with the correct HAR 1.2
structure, and confirmed the base64-encoded image entry decodes back to
byte-identical PNG data (magic bytes checked). Separately applied a
search filter (3 entries -> 2) and confirmed 'E' exported exactly the 2
filtered entries, not all 3 - the same filter-respecting behavior the
status line and help text both claim.

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

1 files changed, 21 insertions, 0 deletions

diff --git a/README.md b/README.md
index df744ba..f0bcc0c 100644
--- a/README.md
+++ b/README.md
@@ -158,6 +158,7 @@ below is enough to get going.
 | `c` | mark for comparison - press `c` on another entry to diff |
 | `x` | delete the selected entry (asks `y`/`n` to confirm) |
 | `X` | clear ALL history, not just the current search filter (asks `y`/`n` to confirm) |
+| `E` | export the current view (respects an active search filter) as a HAR file |
 | `d` | Decoder |
 | `/` | search |
 | `m` | match-and-replace rules |
@@ -191,6 +192,26 @@ standard, URL-safe, padded, and unpadded variants in turn rather than
 requiring you to know which one you're looking at. Single-transform
 only - not chained/pipelined the way Burp's Decoder supports.
 
+### Export
+
+Two independent export paths, both a modal path-prompt (`enter` writes
+and confirms, `esc` cancels):
+
+- `e` from Detail view exports the single selected entry - request and
+  response raw bytes, plain text, exactly what Detail view already
+  shows. Each side is annotated when it isn't wire-exact (truncated or
+  reconstructed), matching Detail view's own labels.
+- `E` from the history list exports the current view - the visible,
+  filtered set if a search is active, everything otherwise - as one
+  [HAR](https://en.wikipedia.org/wiki/HAR_(file_format)) file, for
+  importing into Chrome/Firefox DevTools, Burp, Postman, or anything
+  else that reads HAR 1.2. A binary body (an image, say) is base64-
+  encoded in the HAR rather than corrupted as text. An entry that fails
+  to fetch or parse is skipped rather than aborting the whole export;
+  the status line reports how many, if any.
+
+There's no import yet (see `PLAN.md`).
+
 ### Search syntax
 
 Plain text searches headers and bodies on both sides of the exchange.