fix: populate dropdown cache on demand for limited-visibility users (ENG-7919)

[tvansteenburgh]

ENG-7919

what

When validating a query-backed dropdown parameter, run the dropdown query
on demand (run_if_not_cached=True) if it isn't already cached for the
requesting user's db_role, instead of failing.

why

Limited-visibility (SSO/RLS) users each connect under a distinct per-user
db_role, and cached query results are row-level-isolated by db_role. The
parameter-validation path called dropdown_values(..., run_if_not_cached=False),
so a user whose db_role had no cached dropdown result raised
DropdownSubqueryError ("cached results not found"), which was swallowed into
a misleading InvalidParameterError ("parameter values are incompatible with
their definitions"). Every widget on a dashboard with query-backed dropdowns
then errored for that user.

The two dropdown-fetch endpoints already pass run_if_not_cached=True; only the
validation call site did not. The manual workaround (each user opening the
dropdown queries and clicking Refresh) populated their own db_role's cache, but
had to be repeated per user. This makes that automatic, per db_role, at
validation time. The on-demand subquery runs as the user, so RLS scopes the
cached result correctly.

testing

Added a regression unit test asserting the query-parameter validator invokes
dropdown_values with run_if_not_cached=True. Ran the module via
just backend-test tests/models/test_parameterized_query.py -> 38 passed.

docs

No user-facing docs needed.

🤖 Generated with Claude Code