fix: reword snapshot timestamp mismatch warning to point at snapshot_get_time

[HannanNaeem]

Resolves https://github.com/dbt-labs/fs/issues/14450
Ports: #16106

Problem

The SnapshotTimestampWarning (Q043) message misdescribes both the cause and the fix:

Data type of snapshot table timestamp columns (DATETIME) doesn't match derived column 'updated_at' (DATETIMETZ). Please update snapshot config 'updated_at'.

Two problems:

1. It names the wrong columns. The mismatch is between the type returned by snapshot_get_time() and the updated_at-derived timestamp columns. snapshot_get_time() only feeds written values when closing out hard-deleted rows, so "snapshot table timestamp columns" is misleading about what is actually affected.
2. It recommends the wrong remediation. Changing the snapshot's updated_at config does not resolve the mismatch — updated_at points at the user's own source column, and repointing it changes snapshot semantics. The actual fix is to override snapshot_get_time so it emits a matching type.

Users have reasonably read this warning as "your updated_at config is wrong" and gone looking for a problem that is not there.

Solution

Reword the message:

Data type of snapshot table hard-delete timestamps (DATETIME) does not match its 'updated_at'-derived timestamp columns (DATETIMETZ). Values written when closing out deleted rows will be implicitly converted. Override the 'snapshot_get_time' macro in your project to emit a matching type.

This states what is actually affected (hard-delete timestamps), what the consequence is (implicit conversion on closeout), and the remediation that works.

This is a port of the same fix already made in Fusion. The wording matches that implementation word for word, with two deliberate omissions: Fusion interpolates the snapshot name and appends a --> path location hint, neither of which is available here because the Q043 proto message carries only the two data-type strings. Adding them would require a new proto field in proto-python-public and is out of scope.

This is only half the fix. The warning also fires when it should not — under the default hard_deletes: ignore, snapshot_get_time() never feeds a written column, so the comparison is a false positive. That gate lives in check_time_data_types in dbt-adapters and is handled in a companion PR: dbt-labs/dbt-adapters#.

Merge order matters. This PR must merge first. core/hatch.toml installs dbt-adapters from @main unpinned, so the companion PR reaches this branch's CI the moment it merges. tests/functional/snapshots/test_snapshot_timestamps.py therefore gains hard_deletes: invalidate on its fixture here, which keeps it green against both the current and the gated macro — making this PR safe to merge in isolation and in either order relative to the companion.

Testing

• tests/functional/snapshots/test_snapshot_timestamps.py — assertion updated to the new wording, fixture given hard_deletes: invalidate. Passes against the current unmodified dbt-adapters@main, and confirmed to fail if the types.py change is reverted.
• Full tests/functional/snapshots/ suite: 43 passed — confirms hard_deletes: invalidate does not otherwise perturb the fixture.
• tests/unit/test_events.py passes unmodified; it constructs Q043 but asserts nothing about its text.

A negative regression test (no warning under the default hard_deletes) is deliberately not included here — it cannot pass until the companion dbt-adapters PR merges. It will follow.

dbt-labs/dbt-adapters#2174

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.