feat(packets): server-side exclusion of packet types in /api/packets for the type filter and Hide CONTROL #242

Relates to #96, #211

Problem

The packets page fetches at most PACKET_LIMIT packets for the time window: 1,000 on mobile and 50,000 on desktop. It then filters by type on the client. This applies both to the type filter and to the Hide CONTROL checkbox from #96 / #211.

If the newest packets in the window are all of an excluded type, the filtered list is empty, and there is no way to load older matching packets. /api/packets can only include a single type; it cannot exclude one.

This was found in a Codex review of #211 and documented there as a known limit shared with the type filter.

Proposal

• Add a server-side exclusion parameter to /api/packets, e.g. excludeTypes=11 or a type set, and support it in QueryPackets and the grouped (groupByHash) path.
• The packets page sends it when Hide CONTROL is on, or when the type filter excludes types, and refetches once when the selection changes. No per-item calls.
• Keep the client-side filter for live WebSocket packets.
• Perf: filtering happens in the existing in-memory query path, with no extra pass over the store per request. Include a benchmark with a large store.

Acceptance

• With Hide CONTROL on and a window whose newest PACKET_LIMIT packets are all CONTROL, older non-CONTROL packets are shown.
• The same works for the type filter.
• The API is documented in the OpenAPI spec and docs/api-spec.md. Unknown values are ignored, or rejected with 400.
• Unit tests for the store query and an E2E with a delayed or capped fixture.