nwhitehouse gives tabular review a verified column and real filters

User-facing: filter the table by flag, verified state, and per-column
text predicates. Mark cells verified with a hover ✓ button so the
verified-state filter has something to bite on. Critical when reviews
have more than ~50 docs and the user is hunting for "just the red
ones" or "the cells I haven't checked yet".

Backend:
- Migration 006: tabular_cells gains verified bool (default false),
  verified_at timestamptz, verified_by uuid → auth.users. Additive,
  safe against live data.
- PATCH /tabular-review/:reviewId/cells/verify - toggles a single
  cell's verified state. Records who/when. Reuses ensureReviewAccess.

Frontend:
- trFilterPredicate.ts - pure (cell, filter) → boolean +
  computeVisibleDocIds(docs, cells, filters) → Set<docId>. Operators:
  contains / does not contain / is / is not / is empty / is not empty.
  AND across multiple filters. Flag + verified filters union per-doc;
  text filters scoped to their column. 11 unit tests pass.
- TRFilterBar.tsx - pill row above the table. Active-filter pills with
  ✕ removal. + Add filter popover with Flag (multi-select) / Verified
  (radio) / Column-value (column → operator → value) tabs.
  "Showing N of M documents matching K filters" caption. Clear all link.
- TabularCell.tsx - hover-revealed ✓ button (top-left). Always visible
  when verified (subtle green check); fades in on hover when not.
- TabularReviewView wires filter state in localStorage per
  (review, device); applies via computeVisibleDocIds composed on top of
  the existing doc-name search; mounts TRFilterBar above the table when
  any columns exist; passes onToggleVerifyCell to TRTable.
- TRTable threads the verify handler through to TabularCell and grows
  pl-4 padding when verify is enabled so the ✓ doesn't overlap content.
- TabularCell type extended with verified / verified_at / verified_by;
  no API mapping change needed (Supabase JS auto-includes selected
  columns, and TabularReviewDetailOut → TabularCell[] passes through).

mikeApi: setTabularCellVerified helper added.

Verified: tsc clean both sides; 11 new frontend predicate tests pass via
bun test; 16 backend tests still pass; migration 006 applied locally
(verified column non-null with default false; verified_at + verified_by
nullable).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

User reported the Add filter popover rendered with empty middle -
turned out the sticky doc-name column in TRTable runs at z-[60] and
the popovers were at z-30, so the table cells were painting over the
popover content. Bumped both popovers (TRFilterBar add-filter +
ColumnVisibilityMenu) to z-[80] so they sit above the sticky cells
but below modal overlays at z-[100]+.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Two real bugs from smoke testing:

- Adding the same flag/verified filter multiple times stacked them and
  silently AND'd the conditions (Flag: Yellow + Flag: Yellow,Red →
  matches docs that have BOTH a yellow cell AND a {yellow|red} cell).
  Worse, Verified-only AND Unverified-only is logically empty (no cell
  is both).
  Fix: at most one Flag filter and one Verified filter. Selecting
  either kind in the Add Filter popover replaces the existing one
  rather than stacking. Text predicates can still stack (different
  columns are useful AND-combinations).
  The popover form pre-fills from the existing filter of the same
  kind, so re-opening edits in place.

- The popover anchored at left-0 of the trigger; with many active
  filters the trigger sits at the right end of the row and the
  popover ran off the right edge of the viewport, half-clipped.
  Fix: anchor at right-0 so it grows leftward from the trigger and
  always stays in-viewport.

Bonus: the popover's default tab now picks the *missing* kind
(Flag → Verified → Column value), so building a multi-facet filter
set takes one fewer click.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The earlier fix flipped the popover to right-0 always, which clipped
off the LEFT edge when the trigger was at the start of the row (the
common no-filters-yet case). Now measures the trigger's
getBoundingClientRect on open: if there's >= 320px of room to the
right of the trigger use left-0; otherwise right-0. Recomputed on
every open since the trigger moves as filters wrap.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>