API: Clarify atomicity requirements for SupportsNamespaces.dropNamespace

### Query engine

None — custom catalog implementation backed by FoundationDB

### Question

I am implementing a FoundationDB-backed catalog and would like to clarify the concurrency contract of `SupportsNamespaces.dropNamespace` before choosing the implementation semantics.

The current Javadoc says that the method drops a namespace, returns `true` if it was dropped, and may throw `NamespaceNotEmptyException` when the namespace is not empty. It does not state whether checking emptiness and deleting the namespace must be atomic with respect to concurrent catalog operations.

For example:

1. `dropNamespace(ns)` observes no child namespaces, tables, views, or other objects.
2. A concurrent `createTable(ns.table)` commits successfully.
3. `dropNamespace(ns)` deletes the namespace and returns `true`.

Should the API require behavior equivalent to a linearizable conditional delete? In the example above, I would expect either the drop to linearize first and the concurrent create to fail, or the create to linearize first and the drop to fail with `NamespaceNotEmptyException`. A successful drop should not invalidate or orphan an object that committed before the drop.

Built-in implementations appear to provide different levels of protection:

- `InMemoryCatalog` checks children, tables, and views under the same monitor.
- Nessie performs a commit and maps a server-side `NAMESPACE_NOT_EMPTY` conflict.
- Hive and BigQuery delegate restricted deletion to one backend operation.
- JDBC, Glue, DynamoDB, and ECS perform separate list/check and delete operations.
- The REST specification says only that the namespace must be empty.

FoundationDB can perform the emptiness check and namespace deletion in one serializable transaction, and that is the behavior I currently plan to implement. I would like to confirm whether this is required by the API, recommended as a stronger implementation guarantee, or intentionally left implementation-specific.

Start with the SupportsNamespaces.dropNamespace Javadoc and compare the behavior described for InMemoryCatalog, Nessie, Hive, BigQuery, JDBC, Glue, DynamoDB, and ECS. Review the REST specification's empty-namespace requirement; done means the API's concurrency contract is decided and the relevant documentation clearly states it.

Written by the indexing model from the issue text.