Hive: dropTable silently drops an Iceberg view

**Apache Iceberg version**
main @ 8550723a7

**Query engine**
None — the bug is in `HiveCatalog` and is engine-agnostic.

**Please describe the bug**
`HiveCatalog.dropTable(identifier, false)` does not check whether the identifier refers to an Iceberg view, so it silently drops the view and returns `true` (`HiveCatalog.java` line 240-289). The only view check is `ops.current()`, which sits inside the `if (purge)` branch, so `purge=false` reaches `client.dropTable(...)` unvalidated. HMS `drop_table` does not distinguish tables from views.

This breaks the `Catalog.dropTable` contract: "true if the table was dropped, false if the table did not exist" (`api/.../catalog/Catalog.java` line 305). A view is not a table.

It is inconsistent within the class too: `tableExists(viewId)` returns `false`, yet `dropTable(viewId, false)` drops that view. `registerTable` (line 943-949) and both builders already guard against table/view confusion; `dropTable` is the only path missing it.

`InMemoryCatalog`, `JdbcCatalog`, and REST already return `false` here; HiveCatalog is the only catalog affected.

**Steps to reproduce**
1. Create an Iceberg view `v` via `HiveCatalog`.
2. Call `catalog.dropTable(v, false)`.

Expected: returns `false`, view survives.
Actual: returns `true`, the view is gone.

With `purge=true` the same call instead propagates `NoSuchTableException`, so behavior splits on the `purge` flag.

**Additional context**
N/A

Start in HiveCatalog.java lines 240-289 and compare dropTable with the existing view checks in registerTable and the builders. Check the Catalog.java contract at line 305, then reproduce the purge=false case with an Iceberg view. Done means a view survives and returns false, while table dropping retains its expected behavior.

Written by the indexing model from the issue text.