[FEAT] Make `dbt clone` capability-aware for DuckDB backends

**Is your feature request related to a problem? Please describe.**
`dbt clone` on DuckDB is currently in an awkward state.

There is already a Fusion conformance bug in [#1591](https://github.com/dbt-labs/dbt-core/issues/14508): Fusion does not resolve the clone fallback materialization the same way dbt-core does. But even after that is fixed, the current fallback behavior is still not a good experience for DuckDB.

Today, DuckDB does not support native zero-copy table cloning in open-source DuckDB SQL. When `can_clone_table()` is false, clone falls back to creating views. That is often not useful for DuckDB:

- Vanilla DuckDB commonly uses separate database files for different targets, so the dev target cannot necessarily reference relations from the prod target.
- Even when a view fallback is technically created, it is not equivalent to a real clone for workflows like CI on incremental models.
- The current behavior can make it look like DuckDB "supports clone" when the result is either unusable or materially different from what users expect.

At the same time, "DuckDB" is broader than just local file-backed DuckDB. The adapter ecosystem also includes backends and table formats where metadata-only or zero-copy semantics may become possible (for example MotherDuck-backed environments, DuckLake-backed relations, or Iceberg-backed catalogs).

**Is your feature request related to a particular component of the dbt Fusion Engine**
- [ ] CLI Features
- [x] Adapter or Database Driver Features
- [ ] SQL Understanding Features
- [ ] VS Code extension

**Describe the solution you'd like**
Make `dbt clone` capability-aware for DuckDB in Fusion.

Concretely:

1. Detect whether the active DuckDB backend/target can actually support clone semantics.
2. Only enable clone behavior for DuckDB when the underlying backend explicitly supports it.
3. For unsupported DuckDB scenarios, fail fast with a clear and actionable message instead of silently falling back to a view that may not work or may not preserve clone semantics.
4. Leave a clean opt-in path for future backend-specific support.

A message along these lines would already be a big improvement:

> `dbt clone` is not supported for this DuckDB target. Open-source DuckDB does not provide native zero-copy clone semantics, and the fallback view strategy may not work across separate database files. Clone may only be supported for specific DuckDB-backed platforms that expose native clone capabilities.

This would let Fusion behave well in two directions:

- be honest and explicit for vanilla DuckDB today
- be ready to support DuckDB-backed platforms conditionally when they expose real clone capabilities

**Describe alternatives you've considered**
1. Keep the current fallback-to-view behavior for all DuckDB targets.
This is simple, but it is misleading in practice because the fallback is often unusable or semantically different from clone.

2. Treat DuckDB clone as universally unsupported.
This is safer than the current behavior, but it closes the door on backend-specific support in platforms layered on DuckDB.

3. Fix only [#1591](https://github.com/dbt-labs/dbt-core/issues/14508).
That would fix the Fusion/dbt-core conformance bug, but it would not solve the underlying UX problem for DuckDB users.

**Additional context**
A useful split might be:

- `#1591` tracks the immediate Fusion conformance bug around clone macro/materialization resolution
- this feature request tracks capability-aware DuckDB clone behavior and graceful unsupported-mode messaging

Related context:

- In dbt-core, adapters that cannot clone fall back to views.
- That fallback is already problematic for some clone workflows, especially incremental CI, because a view is not a true substitute for a cloned table.
- For DuckDB specifically, file-based targets make the fallback even more fragile because cross-target references may not be available.

The main ask here is not "make open-source DuckDB support clone," but rather: let Fusion distinguish between DuckDB environments where clone is impossible, and DuckDB-backed environments where clone could be supported now or in the future.