Follow-up to #1391: hash long base identifiers before appending __dbt_tmp / __dbt_backup suffixes

[sd-db]

Context

PR #1391 adds a __post_init__ validator on DatabricksRelation that raises a clear DbtRuntimeError when an identifier exceeds Databricks' 255-character limit. This is a nice improvement over the prior cryptic Unity Catalog RPC error and closes #1309.

One residual surface was flagged during code review: when a user has a base identifier close to the limit (e.g., 247+ chars), the adapter builds derived intermediate relations by appending a suffix like __dbt_tmp (9 chars) or __dbt_backup (12 chars). The derived name exceeds 255 and the new validator raises at construction time — even though the user's base identifier was itself valid.

A unit-level reproduction confirms this:

• Base 248 chars + __dbt_tmp (9) = 257 → validator raises at make_intermediate_relation time.
• Base 255 chars (exactly at limit) + any suffix → same.

This is technically correct behavior (the server would reject the CREATE anyway), but it surfaces as an error message that references "test name" and "custom alias" — unhelpful for a user who already chose a valid-at-255 base name and hit a limit they didn't know about.

Proposal

Override databricks__make_intermediate_relation (and databricks__make_temp_relation) so that when len(base) + len(suffix) would exceed relation_max_name_length(), the base is hashed-and-truncated before the suffix is appended. Pattern: {base[:N]}_{hash(base)[:8]}{suffix}, sized so the total stays ≤ 255.

This mirrors what dbt-postgres and dbt-redshift do today for analogous derived names, and it uses the relation_max_name_length() helper that #1391 just introduced — so the plumbing is already in place.

Benefits

• Users with near-limit base identifiers stop hitting derived-name errors they can't easily diagnose.
• Error messages for the remaining "truly too long" cases (user-set alias > 255) stay focused on the real cause.
• No behavioral change for users whose identifiers are comfortably under the limit.

Open questions

1. Which suffixes need coverage? Confirmed: __dbt_tmp, __dbt_backup. Others?
2. Hash width — 8 hex chars is probably fine for uniqueness within a single run. Worth benchmarking against dbt-core's truncate_relation_name pattern.
3. Should this ship with fix: enforce 255-character identifier length limit for Databricks relations #1391 or land as a separate PR after fix: enforce 255-character identifier length limit for Databricks relations #1391 merges? Scope-wise I lean toward separate.

Happy to pick this up if there's agreement on the approach.

---

Related: #1391, #1309