fix: replace adapter.warn_once in duckdb__apply_grants for Fusion compatibility

[pgoslatara]

Under dbt-core 2.0.0 / Fusion, dbt build fails for any model that has a grants config with:

[JinjaError (dbt1501)]: Error executing materialization macro
'dbt_duckdb.materialization_table_duckdb' for model ...:
Failed to eval the compiled Jinja expression unknown method:
map has no method named warn_once
  (in dbt_internal_packages/dbt-duckdb/macros/adapters.sql:259:7)
  (in dbt_internal_packages/dbt-adapters/macros/adapters/apply_grants.sql:152:31)

The call site is duckdb__apply_grants in dbt/include/duckdb/macros/adapters.sql, which invokes adapter.warn_once(...). warn_once is defined in dbt/adapters/duckdb/impl.py and is decorated with @available, so it works fine under the legacy Python Jinja runtime. Fusion's Minijinja-based runtime, however, does not expose @available-decorated adapter methods on the adapter proxy — it sees the proxy as a generic map and the call fails. The same model build succeeds under dbt-core 1.x.

This PR keeps the original intent of #458 (tolerate grants on DuckDB without crashing the parser) while making the macro work under both runtimes. exceptions.warn is part of the standard dbt Jinja context, so it is bound in Python Jinja and Minijinja alike.

 {% macro duckdb__apply_grants(relation, grant_config, should_revoke=True) %}
     {#-- If grant_config is {} or None, this is a no-op --#}
     {% if grant_config %}
-      {{ adapter.warn_once('Grants for relations are not supported by DuckDB') }}
+      {% do exceptions.warn('Grants for relations are not supported by DuckDB') %}
     {% endif %}
 {% endmacro %}

Trade-off: exceptions.warn does not dedup, so a project with N models configured with grants will see N warnings per run instead of one. That seems acceptable as the cost of cross-runtime compatibility, but happy to take a different approach (for example deleting the override entirely and falling back to the default apply_grants, matching dbt-clickhouse/dbt-exasol/dbt-salesforce) if maintainers prefer.

Refs: #458, #559.

[jwills]

eh I'm more concerned that the fusion adapter doesn't support "at-available" since we use it all over the place in here /cc @dataders

[dataders]

@pgoslatara @jwills I just opened dbt-labs/dbt-core#15211 to discuss next steps with this! likely this solution is what we can adopt, but wanna get the ducks in a row first.

I also opened an internal thread about it