Nessie: listNamespaces checks the parent namespace at a stale ref hash

**Apache Iceberg version**
main @ 9d7b2c52f

**Query engine**
None — the bug is in the Nessie catalog client, so it is engine-agnostic.

**Please describe the bug**
`NessieIcebergClient.listNamespaces(Namespace)` reads two different commits in one call, so listing a namespace another client just created fails with `NoSuchNamespaceException`.

The parent existence check calls `api.getContent().reference(getReference())` (`nessie/src/main/java/org/apache/iceberg/nessie/NessieIcebergClient.java` line 276). `getReference()` returns the `Reference` the client cached when it first resolved the ref, hash included, so the server answers from that older commit.

The child listing a few lines below uses `withReference(api.getEntries())` (line 291), which sends only the ref name for a mutable reference, so the server answers from the HEAD of the ref.

`loadNamespaceMetadata()` in the same class already reads namespace content through `withReference(api.getContent())` (line 380).

**Steps to reproduce**
1. Open two Nessie catalogs on the same server and branch; let both resolve the ref.
2. From client A, create `db1`, then `db1.sub1`.
3. From client B, call `listNamespaces(Namespace.of("db1"))`.

Expected `[db1.sub1]`, actual `NoSuchNamespaceException: Namespace does not exist: db1`.

**Additional context**
The check came in with #12901 (fix for #12875).

Start in nessie/src/main/java/org/apache/iceberg/nessie/NessieIcebergClient.java, focusing on listNamespaces(Namespace), getReference(), withReference(api.getEntries()), and loadNamespaceMetadata(). Reproduce the two-client scenario from the issue, then verify that listing a namespace created by the other client reads the current branch state and returns db1.sub1 instead of NoSuchNamespaceException.

Written by the indexing model from the issue text.