Wire Report actions, harden /api/analyze errors, enrich HAR picker

[marky224]

Summary

Three small, independently revertable changes:

• Item 1 (P1 bug): Re-run and Export markdown now work; Share report is hidden in v1 (persistence is out of scope). Re-run re-fires the input that produced the current Report (composer state / uploaded HAR / fixture / captured DevTools entry). Export markdown copies a TS port of core.render.markdown to the clipboard with a transient "Copied" indicator. Comment in ReportView gates re-enabling Share once persistence ships.
• Item 2 (bug investigation + category fix): Could not reproduce the specific httpbin/401 symptom against the deployed Lambda — every plausible chrome.devtools.network.Request payload shape (rich + minimal, with/without headers, with status as int/string) produced the expected auth.missing finding end-to-end. The trace surfaced a real category bug: malformed entries with missing request.method / request.url or non-integer / out-of-range response.status were escaping as KeyError or Pydantic ValidationError and yielding silent 500s. parse_har now validates required request fields up front; the Lambda handler also catches KeyError so any post-parse engine failure returns a 400 with detail rather than a generic 500. expired.badssl.com is now a named example in extension/README.md known-limitations.
• Item 3 (enhancement): HAR picker post-upload display adds uncompressed file size, capture date (log.pages[0].startedDateTime preferred, entries[0].startedDateTime fallback), and unique-host count. Fields omit cleanly when absent. Strip-banner placement unchanged.

Decisions worth flagging

• Re-run scope: prompt offered Run-tab-only vs. universal. Picked universal because the prompt's later requirement (extension panel re-analyzes the captured DevTools entry) is only achievable that way. Documented in a comment at the top of ReportView.tsx.
• Markdown renderer location: TS port of the Python renderer in frontend/src/lib/markdown.ts. The Report is already in React state with all data needed, so client-side keeps it less invasive than a backend round-trip.
• No targeted fix for the httpbin/401 symptom: I exhaustively traced the analyze pathway and the production Lambda returns the correct Report for that input. If the symptom persists in real-browser testing, the next investigation should look at runtime JSON.stringify of a real chrome.devtools.network.Request (some properties may be non-enumerable getters) — the regression tests added here will catch any drift in either the parser shape or the panel render path.

Test plan

• pytest — 330 passed (was 322; +8 across test_parser.py and test_lambda_handler.py)
• ruff check . — clean
• ruff format --check . — clean
• frontend tsc -b — clean
• extension tsc -b — clean
• frontend vitest — 73 passed (was 66; +7 in ReportView/RequestComposer/HarUpload)
• extension vitest — 17 passed (was 16; +1 regression for the 401 path)
• frontend npm run build + extension npm run build — both succeed
• Manual browser smoke: load frontend via npm run dev, exercise Run / HAR / Demos tab actions; load extension/dist/ unpacked and exercise the panel against https://httpbin.org/status/401. Recommended before merge — sandbox couldn't drive a browser.

Out of scope (noticed, not fixed)

None on the paths I touched.

🤖 Generated with Claude Code