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, 13 insertions, 1 deletions

diff --git a/README.md b/README.md
index 7058180..4a9def0 100644
--- a/README.md
+++ b/README.md
@@ -159,6 +159,7 @@ below is enough to get going.
 | `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) - `.har` or `.csv` |
+| `I` | import a HAR file's entries into history |
 | `d` | Decoder |
 | `/` | search |
 | `m` | match-and-replace rules |
@@ -228,7 +229,18 @@ format-selection control:
     is neutralized with a leading quote before writing, the standard
     CSV-injection mitigation.
 
-There's no import yet (see `PLAN.md`).
+### Import
+
+`I` from the history list reads a HAR file and inserts its entries into
+history, tagged `source:import` so they're easy to find or filter out
+later (`source:import` in search). Works with a HAR from mitmux itself
+or from anywhere else that produces one - Chrome/Firefox DevTools, Burp,
+Postman. An entry that fails to convert is skipped rather than aborting
+the whole import; the status line reports how many, if any. Imported
+entries are always shown as "reconstructed" (never "exact") - they're
+rebuilt from HAR's structured fields, not the literal bytes that were
+actually on the wire for the original request, same situation an
+HTTP/2 capture is already in.
 
 ### Search syntax