feat(frontend): make a table search show it is loading, from keystroke to results

[archestra-task-envs]

Problem

Typing in a table's search box produced no feedback of any kind until the
results themselves changed.

Three things had to line up for that to be as silent as it was:

• SearchInput renders a static <Search> magnifier and hands the field to
  DebouncedInput, which sits on the keystroke for 400ms before telling anyone.
  Nothing in the tree could even ask whether a keystroke was waiting in that
  timer, so the first 400ms of every search were unacknowledged by construction.
• DataTable's isLoading prop only ever suppressed the empty state — the
  {!isLoading && <EmptyState .../>} branch in the fallback row. Once rows were
  on screen it did nothing at all.
• These lists use placeholderData: (previousData) => previousData, so the
  previous page stays on screen while the next one loads. Combined with the
  point above, a refetch changed nothing on screen until the new rows landed.

So the whole wait — debounce, commit, request — passed under an unchanged
magnifier above an unchanged table. A slow search was indistinguishable from a
box that had swallowed the query.

The fix

One continuous signal from the keystroke to the results, in three parts.

DebouncedInput reports its pending window

New onPendingChange callback. The window opens on the keystroke, not when
the debounce fires — the gap being covered starts when the user types.

Closing it is the subtler half. It closes when the committed value catches up,
because that is also the moment the caller's fetch starts, so an indicator
driven by this hands over to one driven by that without blinking off in
between. A caller that keeps its query somewhere other than initialValue (a
purely local onSearchChange) never produces that moment, so the window is
also bounded by a short handoff timer — a stuck indicator is the one failure
worth ruling out entirely.

The search box lights up

The magnifier cross-fades into a spinner. Both icons stay mounted in the same
16px slot and swap opacity, so nothing in the field moves and a box that is at
most one debounce away from busy does not flicker its icon on every keystroke.

The pending window drives it with no wiring at all, so every call site gets
the acknowledgement typing was missing. A new isLoading prop extends it
across the request that follows.

The spinner is aria-hidden; the field carries aria-busy, so assistive tech
hears the state without a live region announcing every pause between
keystrokes.

The table marks itself busy

An indeterminate bar sweeps the table's top edge, and the rows a refetch is
about to replace fade back so they stop reading as current.

Deliberately not a spinner in place of the rows: replacing them would
collapse the table's height on every keystroke, which is the flash the existing
empty-state handling already goes out of its way to avoid. Both effects are
delayed ~150ms so a refetch that resolves immediately never registers as a
flicker; rows return to full strength undelayed.

Two details worth flagging for review:

• The bar is a sibling of the overflow-x-auto container, not a child. An
  absolutely positioned child of it scrolls away with the content on a table
  wide enough to scroll. This is why data-table.tsx gains a wrapper <div> —
  and why its diff is mostly re-indentation.
• It is a progressbar, not a live region. isLoading is true for background
  refetches too, and those should not be announced. The table also carries
  aria-busy.

Which pages get the fetch flag

Only pages whose search term actually reaches the query. Where the search is a
client-side filter over an already-loaded list — connector members and user
groups, LLM models, service accounts, plugins, API keys, the MCP catalog tabs —
the page's isFetching describes loading that list, not searching it, so
wiring it would light the box for something the user did not ask for. Those
keep the debounce-only indicator, which is the honest one there: their results
land the instant it ends.

Scope

The report was about one page's search box; the cause was in the shared
components behind it, so the fix is applied there and every table search
benefits. Verified in a browser against the running stack at both a desktop
width and narrowed, with the request artificially held open to make each state
observable, and with the previous-page-retained case exercised specifically.

Tests pin the pending window's four transitions (opens at the keystroke,
survives the commit, self-closes when no commit arrives, never opens for an
edit that lands back on the committed value), that the field reports busy for
both halves, and that the table announces a refetch without disturbing the rows
already on screen. The two DataTable tests that asserted the absence of an
indicator during loading were updated rather than left to pass by accident.

motion-reduce covers both animations: the spinner stops, and the bar holds
still and fills its track instead of sweeping.

---

Follow-up: the sidebar spinner sits out searches

Steered mid-flight — the first version left the sidebar toggle's spinner
spinning during a search, which put three indicators on screen for one
wait: the lit search box, the table's progress bar, and a spinner in the corner
furthest from where the user is looking.

That spinner is still the right thing for boot and page transitions, so it is
not removed — it now sits out searches specifically. SearchInput reports its
in-flight state (the same flag that drives its own spinner, so the two cannot
disagree) and useIsAppLoading stands down while any search box is waiting. A
counter rather than a flag, because a page can hold more than one search box
and the first wait to finish must not speak for the second.

Why the search box has to be the one to say so. This is not inferable from
the query. Changing the search term changes the query key, so the entry being
fetched has data === undefined and matches useIsAppLoading's predicate —
even on the lists that keep their previous page on screen, because that page
lives on the observer, not in the new cache entry. Confirmed by measurement,
not by reading: on the skills list the spinner reached 0.8 opacity mid-search
before this change.

The two halves stay separate by construction. The toggle is
isNavigating || isAppLoading, and only the second half is suppressed.
isNavigating is set by clicks on internal anchors and never by the
router.push a search commit makes, so page transitions are untouched.

Verified in a browser: sampling the toggle's spinner opacity every 50ms across
an entire slow search (100 samples) it never leaves 0, while a page transition
still takes it to 0.8.

---