Import: bring a HAR file's entries into history

Closes the interop loop HAR export opened - traffic can now move both
directions between mitmux and any other HAR-producing tool (browser
DevTools, Burp, Postman), not just out.

cmd/mitmux/har.go: rawRequestFromHAR/rawResponseFromHAR reconstruct
HTTP/1.1 wire bytes from HAR's structured fields - the mirror image of
harEntryFromDetail on the export side. Deliberately tolerant of a HAR
file that didn't come from mitmux at all: lowercase header names,
"HTTP/2" in httpVersion, missing optional fields like postData, a
redirectURL nobody filled in. Content-Encoding and Transfer-Encoding
headers are stripped from the reconstructed response before writing it
- HAR's content.text is already decoded per spec, so re-emitting those
headers would describe framing the body no longer has and break any
client that tried to decode it again - and a Content-Length is computed
if the HAR didn't carry a consistent one. importEntriesFromHAR converts
a whole document, skipping (not failing on) any entry that fails to
convert, same reasoning as export's own skip-and-continue for a
malformed capture.

Imported entries are always request_exact=false/response_exact=false:
reconstructed from structured HAR fields, the same situation an HTTP/2
capture is already in, never claiming to be the literal bytes that were
actually on the wire for the original request.

internal/ipc: ImportEntry (the slim shape the client sends - the daemon
just stores what it's given, all HAR parsing happens client-side) and
an "import" request type; Client.Import returns how many entries were
actually inserted, a per-entry store failure is skipped rather than
aborting the batch. Server-side, imported entries are tagged
source="import" so source:import finds them in search, same as
source:repeater/source:intruder already work.

TUI: 'I' from the history list prompts for a HAR path (same modal
pattern as export, in reverse - reading instead of writing), then
reloads the list and status once the import completes.

Verified live: exported real captured traffic to HAR, cleared history
entirely, imported the same file back and got both entries with
correct content (byte-different after the round trip - headers get
reordered/reformatted - but semantically identical, correctly labeled
"reconstructed" rather than falsely "exact"); hand-built a HAR mimicking
a real Chrome DevTools export (lowercase headers, HTTP/2, a base64-
encoded binary PNG body, several optional fields omitted) and confirmed
it imports cleanly with the binary body decoded correctly (PNG magic
bytes verified byte-for-byte); confirmed a missing file and invalid
JSON both fail with a clear error and no crash, history left untouched.

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

1 files changed, 37 insertions, 2 deletions

diff --git a/PLAN.md b/PLAN.md
index a070b20..f113bd8 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -336,8 +336,43 @@ injection fix from the robustness audit, just for a different output
 format - captured content controlling the tool that later processes it,
 rather than the terminal that renders it.
 
-Still open from the expanded "worth considering" list: import (no path
-back in yet). Requested explicitly; not started yet.
+Shipped since: import. `I` from the history list reads a HAR file and
+inserts its entries into history, tagged source="import" (so
+`source:import` finds them, same as `source:repeater`/`source:intruder`
+already do). This closes the interop loop HAR export opened: traffic
+can now move both directions between mitmux and any other HAR-producing
+tool (browser DevTools, Burp, Postman), not just out.
+
+The reverse conversion (HAR entry -> raw HTTP/1.1 bytes) is the mirror
+image of HAR export's harEntryFromDetail, deliberately written to
+tolerate a HAR file that didn't come from mitmux at all - lowercase
+header names, HTTP/2 in httpVersion, missing optional fields like
+postData, a redirectURL nobody bothered filling in. Content-Encoding
+and Transfer-Encoding headers are stripped from the reconstructed
+response before writing it (HAR's content.text is already decoded per
+spec - re-emitting those headers would describe framing the body no
+longer has, breaking any client that tried to decode it again), and a
+Content-Length is computed if the HAR didn't carry a consistent one.
+Imported entries are always request_exact=false/response_exact=false -
+reconstructed from structured HAR fields, same situation an HTTP/2
+capture is already in, never claiming to be the literal bytes that
+were on the wire for the original request. An entry that fails to
+convert (an unparseable URL, say) is skipped rather than failing the
+whole import, same reasoning as export's own skip-and-continue.
+
+Verified live: exported real captured traffic to HAR, cleared history
+entirely, imported the same file back and got both entries back with
+correct content (byte-different from the original - headers get
+reordered/reformatted through the round trip - but semantically
+identical, and correctly labeled "reconstructed" rather than falsely
+claiming "exact"); separately hand-built a HAR mimicking a real Chrome
+DevTools export (lowercase headers, HTTP/2, a base64-encoded binary
+PNG body, several optional fields omitted) and confirmed it imports
+cleanly with the binary body correctly decoded (PNG magic bytes
+verified byte-for-byte); confirmed a missing file and invalid JSON
+both fail with a clear error and no crash, history left untouched.
+
+This closes every item from the expanded "worth considering" list.
 
 Skipped deliberately (from the research, matches this tool's stated
 scope): active/passive vulnerability scanning, plugin marketplace,