Dashboard Refresh serializes the Filter wave before the Panel wave for every tile, even unaffected ones

[BorisTyshkevich]

Problem

runAll() in src/ui/dashboard.js:693-695 always does:

await runFilterWave();
const wave = prepareWave();
await runPlan(reservedPlan.map((item) => ({ ...item, src: wave[item.index] })));

Every panel tile — including ones whose SQL references no curated filter
field at all — waits for the entire Filter wave (all Filter-role favorites,
bounded by TILE_CONCURRENCY) to finish before its own query is even issued.
On a dashboard with slow Filter sources and many independent, non-filter-
dependent panels, this adds the full Filter-wave latency to every refresh's
time-to-first-tile.

Why deferred

Found during a pre-merge UI/UX review of #232 (feat/dashboard-filter-sources-160).
The sequencing is deliberate, not accidental: prepareBatch()
(src/ui/dashboard.js:411-417) needs the resolved curatedFields/
filterActive state to correctly blank an inactive curated field's value
before computing each panel's execution plan — panels that DO reference a
soon-to-be-curated name would otherwise run once with the wrong (stale or
unblanked) value and need a second corrective run, essentially
re-implementing runAffected's reconciliation logic as a post-step. That's a
bigger, riskier change to bundle into an already-large fixup pass, and
correctness (every panel sees the right blanked/active value on the very
first pass) is a reasonable tradeoff to keep for now.

Acceptance direction

• Determine, per panel favorite, whether its declared {name:Type} params
  overlap any name a Filter favorite could produce (this requires knowing a
  Filter favorite's own declared/likely output column names — today only
  discoverable by actually running its SQL, so this may need a lighter
  contract, e.g. Filter Specs optionally declaring their intended helper
  names).
• Panels with no possible overlap can run in parallel with the Filter wave
  instead of waiting on it.
• Panels that DO reference a name a Filter wave might resolve must still wait
  (or run once optimistically and be corrected via the existing
  runAffected/merged.changed path once the Filter wave resolves).
• Verify no regression to the "every panel sees the right blanked/active
  value on the first pass" invariant prepareBatch currently guarantees.

[BorisTyshkevich]

Folded into the #280 Dashboard-as-first-class-module refactor and closed per maintainer decision (2026-07-17).

The fix lands in #286 (Dashboard v1 phase 4): the DashboardViewerSession execution planner runs panels whose declared params cannot be affected by any filter source in parallel with the filter wave, while affected panels keep the first-pass blanked/active-value invariant. The missing piece this issue identified — knowing which names a Filter source can produce without running it — is supplied by the explicit DashboardFilterDefinitionV1.parameter/targets contract in #280, so the lighter declaration contract proposed here is exactly what the new model provides. #286 carries a regression-test requirement for both halves.