perf: avoid full snapshot mapping in _resolve_table/_resolve_tables

[mday-io]

Description

Resolving one table during virtual-layer updates previously built and normalized a mapping for every snapshot. _resolve_table now maps only the matching snapshot on an exact lookup, retaining the full-mapping fallback for dialect-dependent name mismatches. _resolve_tables skips snapshot scans and expansion setup when an expression contains no table reference.

During promotion, each target model can receive the broader snapshot context because its expressions and macros may reference other models. Property values go through the same expression renderer as SQL statements. Previously, even a literal virtual property such as description = 'Customer orders' triggered construction of the full snapshot mapping when snapshots were supplied, despite containing no table reference.

This work repeats per rendered property or statement, not just once per plan. For illustration, promoting 1,000 models with three literal virtual properties each and a 1,000-snapshot context would cause 3,000 mapping builds, each visiting 1,000 snapshots. This is a count of avoidable work for that hypothetical workload, not a measured benchmark or timing claim. Empty property collections produce no calls, and calls without snapshots, overrides, or expansion already returned early.

The change targets that unnecessary setup. Expressions containing table references still use the broader mapping, while single-table resolution narrows the snapshot lookup when an exact match is available.

Explicit table_mapping entries retain their dialect-aware matching and precedence, including when an exact snapshot match exists or a later equivalent override follows an exact-key override. The fast path avoids scanning unrelated snapshots; processing explicit overrides remains proportional to the size of that mapping.

Fixes #6017.

Test Plan

• Regression coverage for exact snapshot matches with equivalent override keys, including later-override precedence through a rendered macro.
• Coverage checks snapshot scan counts, cross-dialect fallbacks, mapping without snapshots, expression inputs, expansion, table-less properties, and deployability. The cross-dialect test uses explicit normalization settings to avoid dependence on global dialect state or cached values.
• The previously failing dbt/model test sequence passes (2 tests); focused renderer coverage passes (13 tests).
• make style: passed (Ruff, formatting, mypy, migration validation).
• Fast-test coverage: 2,636 passed / 4 skipped in the main phase; all isolated tests passed, with the two forking tests rerun separately after a DuckDB cleanup hang. Registry and dialect phases passed (1 and 161 tests). The final comment-only edit leaves the Python AST unchanged.
• GitHub CI on 07e2ddf4: DCO/Commits Check passed; the full CI run is still in progress.

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable)
• All existing tests pass (make fast-test)
• My commits are signed off (git commit -s) per the DCO

[mday-io]

Two findings: override-precedence regression and failing formatter check.

[mday-io]

I tested the change against our production-backed monorepo project to understand whether the improvement translated beyond the focused unit tests.

The targeted benchmark confirms the optimization works: repeated resolution against 3,132 production snapshots was substantially faster, and the rendered SQL remained identical. However, a real environment promotion showed no measurable improvement in the virtual-layer stage:

• Baseline: 1.782s
• Patched: 1.790s

A broader render-only run across 1,775 promoted models produced the same conclusion. Most properties in the real project are plain strings and do not exercise the expensive expression-resolution path often enough to affect overall plan performance.

The change appears correct, but the practical benefit is too narrow to justify carrying the additional logic without a real workload demonstrating an end-to-end improvement. I’m going to close this PR for now. We can revisit it if we find a project where table-containing property expressions materially slow promotion.