Flagged marker for history entries

Last of the "should build soon" items from the Burp/ZAP/Caido gap
research - Burp's row highlighting and Caido's Findings both serve
the same real workflow: mark something interesting mid-engagement,
revisit later. Scoped to a boolean flag (★) rather than full free-text
notes/comments, which would need their own text-input overlay for
comparatively modest extra value over a simple marker - tracked as a
real follow-up in PLAN.md, not dropped silently.

internal/store: history gains a flagged column (migrated in for
existing databases the same way source was) plus Store.SetFlagged and
Summary/Entry.Flagged. Search's structured-filter layer (added last
commit for status:/source:) gains flagged:true/false alongside them -
extractStructured already existed for exactly this kind of "pull it out
before it reaches FTS5" filter. internal/ipc gains a "set_flagged"
request. cmd/mitmux: 'f' toggles the flag on the selected history row
(applied optimistically to local state, persisted async - a drift
between local and server state on failure is an acceptable trade-off
for a marker this low-stakes), shown as a ★ column in the list and in
the detail view's title.

store_test.go covers the flagged: parsing (true/false spellings, and
a "looks like it but isn't" case - flagged:maybe - falling through as
literal search text, matching the existing pattern for status:).

Verified live: toggling 'f' shows the star immediately, flagged:true
correctly filtered to just that entry, and a direct SQLite check
confirmed the flag actually persisted to the database (flagged=1),
not just reflected in local UI state.

1 files changed, 28 insertions, 0 deletions

diff --git a/PLAN.md b/PLAN.md
index 64d1a0d..ca379e9 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -74,3 +74,31 @@ hudsucker) - same problem, worth studying even though this build is Go.
   run in a loop with generated bytes - and results land in the same
   history table tagged source="intruder", same as Repeater's
   source="repeater", rather than a separate results store.
+
+## Post-build-order: Burp/ZAP/Caido parity pass
+
+Build order 1-7 is done. Researched what those three actually offer
+(features and basic UI/UX) and triaged the gap into "should build soon"
+/ "worth considering" / "skip" - see commit history for the full list;
+tracking what's shipped vs. deferred here.
+
+Shipped: vi-modal editing for the raw request textareas (table and
+viewport already had vi nav by default - this was specifically about
+textarea/textinput, which don't); a persistent status bar and a '?'
+keybinding reference; display-only response JSON pretty-printing;
+structured search filters (status:, source:, flagged:) alongside the
+existing FTS5 text search; a flagged marker (★) for "revisit this" -
+deliberately simpler than full free-text notes/comments, which would
+need their own text-input overlay for comparatively modest extra value
+over a boolean; noted as a real follow-up, not dropped silently.
+
+Still open from "worth considering": a Comparer (diff) tool, a
+standalone encoder/decoder utility, multiple concurrent Repeater tabs,
+Intruder payload processing (encoding/case rules) and grep-match/
+grep-extract on results, CA install UX per OS, multiple proxy listeners
+and upstream proxy chaining. None of these are started yet.
+
+Skipped deliberately (from the research, matches this tool's stated
+scope): active/passive vulnerability scanning, plugin marketplace,
+Collaborator/OAST, team collaboration, CI integration, client TLS
+(mutual-TLS) certs, invisible/non-proxy-aware proxying.