Add ARP decoding and bring the TUI up to -c/-a parity

ARP had zero treatment until now - its ethertype just fell through
summarize_packet's "not IPv4/IPv6" branch, on traffic that appears on
essentially every real LAN capture. Scoped to Ethernet/IPv4 addressing
(the case that covers virtually all real ARP traffic), with tcpdump's
own "who-has X tell Y" / "X is-at Y" phrasing rather than inventing
new wording. Live-verified by flushing this machine's real gateway
ARP entry and capturing the resulting request/reply on wlp1s0.

TUI -c/-a were being parsed into RenderOptions but silently did
nothing: run_tui()'s consumer thread had its own loop that never read
them, unlike plain-text mode's render_packet(). Fixed to match, and
caught a real bug while doing it - pushing up to two rows per packet
(summary + reassembly line) against a single pop_front() would let
the row deque grow past its cap under sustained -a activity; needed a
while loop instead. Verified under tmux against the same split-segment
HTTP scenario used to verify -a on the CLI and GUI.

1 files changed, 38 insertions, 0 deletions

diff --git a/PLAN.md b/PLAN.md
index 20450d1..5c0f2f1 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -368,3 +368,41 @@ None currently open.
   pass; summarize's own harness also now exercises the ICMP decode path
   added earlier this session and the new mDNS/SSH dissectors, since all
   of that lives inside summarize_packet()'s call graph already.
+- Renamed wireframe -> packeteer (packet + -eer). See NAMES.md for the
+  reasoning and the collisions checked before committing to it.
+- ARP (packeteer/net/arp.hpp): the one real-traffic L2 protocol that
+  had zero treatment until now - an ARP frame's ethertype (0x0806)
+  just fell through summarize_packet's "not IPv4/IPv6, stop after the
+  Ethernet line" branch, on traffic that shows up on essentially every
+  real LAN capture. Scoped to Ethernet hardware addresses (hlen=6) and
+  IPv4 protocol addresses (plen=4) - the case that accounts for
+  virtually all real ARP traffic; other combinations still decode the
+  fixed header (hwtype/protype/opcode) without guessing at a different
+  address width. Summary phrasing deliberately matches tcpdump's own
+  "who-has X tell Y" / "X is-at Y" convention rather than inventing new
+  wording, since that phrasing is already how anyone reading ARP
+  traffic expects to see it. Verified against real traffic: flushed
+  this machine's ARP cache entry for its actual default gateway and
+  captured the resulting request/reply on wlp1s0 - "who-has
+  192.168.1.1 tell 192.168.1.104 (28:39:26:71:cd:dd)" followed by
+  "192.168.1.1 is-at bc:07:1d:ff:54:e9", both addresses matching this
+  machine's real interface/gateway.
+- TUI parity for -c/-a: unlike -x (hex dump, never ported to the TUI),
+  -c/-a were already being parsed into RenderOptions for every mode --
+  main()'s arg parsing doesn't distinguish TUI from plain-text - but
+  run_tui()'s consumer thread had its own separate loop that never
+  read opts.verbose_checksums/opts.reassembler, so the flags silently
+  did nothing in TUI mode despite appearing to be accepted. Fixed by
+  mirroring plain-text render_packet()'s logic: checksum status
+  appended inline to the row, a reassembled-HTTP line pushed as a
+  second row right after, both via the same packeteer::checksum_status/
+  reassembled_http_status() the CLI and GUI already share. Caught a
+  real bug while wiring this in, before it ever ran: pushing up to two
+  rows per packet against a single `if (rows.size() > kMaxRows)
+  pop_front()` would let the row deque grow unboundedly under
+  sustained -a activity, since one pop can't offset two pushes --
+  changed to a while loop. Verified under tmux (capture-pane, not raw
+  pty - see the search-bug methodology note above) against the same
+  split-segment HTTP scenario used to verify -a on the CLI and GUI:
+  both "checksums: IP=ok TCP=..." and "[reassembled request: ... Host:
+  ... (72 bytes so far)]" appeared correctly inline in the packet list.