Status bar shows no signal that the server / dataflow is still computing after a state_change

[paddymul]

Summary

After the user changes search / cleaning / post-processing, the status bar gives no indication whether the resulting grid state is "computed and final" or "still in flight". On a slow backend (xorq @ ~7s per state_change against the boston-restaurant dataset, polars @ ~600ms even with warm caches), this means an empty grid is ambiguous between two very different outcomes:

• The filter returned zero rows.
• The filter is still being computed.

Visible failure mode: user types something, sees an empty grid for a long time, can't tell if the server is hung or just genuinely returned nothing. Their next move is usually to refresh the page (which clears any in-flight work) or click X (which re-fires the cycle).

Scope

Most acute in server mode (slow xorq backends), but also relevant to the widget in any deployment where the dataflow cascade takes more than a few hundred ms — large pandas frames, polars on slow disks, etc. The widget is currently silent in both contexts.

Impact

• Users can't distinguish "computing" from "no results", so they double-click / abandon / refresh, which can compound the problem.
• No way to debug "is the server stuck or is the filter just slow?" without server-side logs.
• Even an indicator that distinguishes "row data is back, stats still coming" from "everything is done" would be useful for the rows-first / progressive-stats work in flight (spike(rows-first): two-message state_change protocol behind env gate #787, feat(paf): process_table_scalars / _aggregates entry points (Phase 2) #809).