fix(duckdb): ensure drop_table handles views to avoid catalog errors

[Retugbo]

Problem: DuckDB maintains a strict distinction between tables and views in its catalog. Invoking DROP TABLE on a view object currently triggers a Catalog Error.

Solution:
This PR introduces a safety check in the drop_table method:

Metadata Inspection: Leverages _get_data_objects to verify the object type at runtime.

Dynamic Routing: If the object is a VIEW, the call is redirected to drop_view.

Signature Integrity: Maintains compatibility with the EngineAdapter superclass while preventing kwargs collisions (specifically the exists flag).

Impact:
Increases the robustness of the DuckDB adapter, preventing workflow interruptions when models are switched between table and view materializations.

[CLAassistant]

All committers have signed the CLA.

[StuffbyYuki]

@Retugbo It looks like some style related test have failed. Could you maybe reformat your change with make style and rerun the cicd runs?

[alessio-giuliano-pix4d]

@Retugbo I am interested in this fix, but your code does not resolve the issue for me in the case of using the DuckDB engine to write in a Postgres database. (Not sure if that's what you tried to fix)

The problem is that the view is already being treated as a table at the level of duckdb-postgres. When the code that was added in this PR is reached, the if condition to run DROP VIEW instead of DROP TABLE is never true. Even if it was, it would fail here (https://github.com/SQLMesh/sqlmesh/blob/main/sqlmesh/core/engine_adapter/base.py#L1446) because the exists parameter is passed through both kwargs from your new drop_table method, and through the line linked above.

I drafted another fix for the problem I am having here: #5809