[Bug] `dbt.date()` fails on DuckDB — no `duckdb__date`, so `default__date` emits unsupported `to_date()`

## Summary

`dbt.date()` has no DuckDB override, so it dispatches to `default__date`, which emits `to_date('YYYY-MM-DD', 'YYYY-MM-DD')`. **DuckDB has no `to_date` function**, so any project calling the documented pattern of `dbt.date_spine()` with `dbt.date()` boundaries fails on a DuckDB target.

`date()` is a [documented cross-database macro](https://docs.getdbt.com/reference/dbt-jinja-functions/cross-database-macros?version=2.0&name=Fusion#date-and-time-functions), and pairing it with `date_spine()` is an intended usage pattern, so this is a plain gap rather than misuse.

## Reproduction

Found and verified while testing dbt-labs/jaffle-shop#103 against dbt-core 1.12 + DuckDB locally.

```sql
{{ dbt.date_spine(
datepart="day",
start_date=dbt.date(2020, 1, 1),
end_date=dbt.date(2021, 1, 1)
) }}
```

Fails on DuckDB because the rendered SQL contains `to_date(...)`.

## Fix

Add a `duckdb__date` override using DuckDB's native `make_date(year, month, day)` constructor, mirroring the existing `bigquery__date` pattern (native constructor rather than string parsing).

## Open question worth resolving alongside

These adapter macros are vendored from `duckdb/dbt-duckdb` — the sibling `dateadd.sql` and `datediff.sql` already carry DuckDB overrides, which is why `date()` stands out as an omission. Worth confirming whether the same gap exists in `dbt-duckdb` itself for the Core v1 path, and if so upstreaming it there too rather than only patching the vendored copy.

## PR

dbt-labs/fs#12243 (open).