Pin month-relative integration tests to a frozen reference date

[Pádraic Slattery (pgoslatara)]

The duckdb integration tests failed intermittently (e.g. run 28499584995) on the six month-relative assertions — last_month_number, last_month_name, last_month_name_short, next_month_number, next_month_name, next_month_name_short — and then passed on re-run with no code changes. This is a month-boundary race, not a real regression.

The last_month_* / next_month_* macros compile to SQL anchored on current_date (via dbt_date.today(tz)). The integration project materialises models as table and sets dbt_date:time_zone: "America/Los_Angeles". So the model column is frozen at dbt run time, while test_dates.yml re-evaluated the same macros at dbt test time. When the two steps straddle midnight-of-the-1st in that time zone (07:00–08:00 UTC depending on DST), they resolve to different months and the assertion fails. The failing run built the model at 23:59:56 PDT (June 30) and asserted at 00:00:01 PDT (July 1); the re-run ran entirely on one side of the boundary, so it was green.

This pins the reference date so the two invocations can't disagree: get_test_dates.sql now captures today() once as a frozen as_of_date column (evaluated in the same statement as the month columns, so it shares their exact instant), and the six assertions in test_dates.yml derive their expected values from that stored column via dbt.date_trunc / dbt.dateadd instead of a fresh today(). The macros are still exercised at dbt run time, so coverage is unchanged.

Verified locally with tox -e dbt_integration_duckdb: 36/36 tests pass.