fix(fusion): dbt State run_cache no longer falls back to per-node queries for legitimately-empty Databricks schemas

[DipakMandlik]

Resolves #15594

Problem

dbt State's run_cache prefetch (run_cache_service.rs) batches a schema-level freshness dump per (database, schema) group via freshness_all_in_schema, and falls back to slower per-node queries — with a StateServiceWarn — whenever that dump comes back empty. The fallback exists specifically to work around Snowflake's INFORMATION_SCHEMA eventual consistency: Fusion's global prefetch fires eagerly at run start, before dbt-core's plugin-style lazy prefetch would have given the catalog a few seconds to catch up on a table from the immediately preceding run.

That reasoning doesn't hold for every adapter. On Databricks, CI jobs that build into fresh per-PR ephemeral schemas hit dump.is_empty() on 100% of schema groups, on every run, adding 60s–5min of per-node fallback queries before the build even starts — because the schema is genuinely brand new, not because of a race.

The root cause is that dump.is_empty() alone is the wrong signal. It conflates "the adapter's bulk lookup mechanism can lag behind a real table" with "there's genuinely nothing here yet," and which one applies depends entirely on how each adapter implements freshness_all_in_schema.

Solution

Read all three currently-implemented freshness_all_in_schema methods plus the trait's default, rather than assuming the bug report's framing, and gate the fallback on which category each adapter actually falls into:

• Snowflake / BigQuery: each issues a single INFORMATION_SCHEMA-style bulk query against a metadata view that's documented to lag behind DDL — the fallback is genuinely necessary here, unchanged.
• Unimplemented adapters: fall through to the trait's default implementation, which deliberately returns an empty map to signal "fall back" (per its own doc comment) — the fallback is the only way those adapters get real freshness data, unchanged.
• Databricks: issues a real per-relation DESCRIBE HISTORY (or INFORMATION_SCHEMA.last_altered for views) lookup directly, with no intermediate eventually-consistent catalog snapshot. An empty result there unambiguously means every relation in the group doesn't exist yet — exactly the state of a freshly created CI schema before any model has run. No longer falls back or warns.

New private helper added: schema_dump_empty_requires_fallback(adapter_type, dump_is_empty) — a small, pure, directly-testable gate function, following the same allow/deny-list pattern already established in this file by heuristic_clock_enabled_for_adapter for an analogous Databricks-specific issue.

Checklist

• I have read the contributing guide and understand what's expected of me.
• I have run this code in development, and it appears to resolve the stated issue.
• This PR includes tests, or tests are not required or relevant for this PR.
• This PR has no interface changes (e.g., macros, CLI, logs, JSON artifacts, config files, adapter interface, etc.) or this PR has already received feedback and approval from Product or DX.
• This PR includes type annotations for new and modified functions.

Automated checks

Check	Command	Result
Build	cargo build -p dbt-tasks-core	exit 0
Lint	cargo clippy -p dbt-tasks-core --all-targets	clean
Unit tests	cargo test -p dbt-tasks-core --lib	90 passed, 0 failed (5 new)