ATTACH with a non-existent DEFAULT_SCHEMA succeeds, then every scan fails with a misleading __internal_delta_ccv2_commit_staged internal error

## Summary

`ATTACH ... (TYPE unity_catalog, DEFAULT_SCHEMA '')` reports success even when the named schema does not exist in the catalog. Catalog metadata then works perfectly - schemas and tables are listed correctly - but the first query that actually reads data fails with:

```
INTERNAL Error: Parent catalog does not have a __internal_delta_ccv2_commit_staged function
```

The stack trace runs through the `delta` extension and names a catalog-commit (ccv2) function, so it reads as a protocol or version mismatch between `delta` and `unity_catalog`. It is neither: the only mistake is a typo in `DEFAULT_SCHEMA`, and nothing in the message, the trace, or the `ATTACH` result points there.

## Environment

| | |
|---|---|
| DuckDB | v1.5.5, `linux_amd64` |
| `unity_catalog` | `fd85147` (stock, from `extensions.duckdb.org`) |
| `delta` | `45c4087` (stock) |
| `httpfs` | `827222f` (stock) |
| Server | Unity Catalog OSS v0.6.0 |

Reproduced independently on two unrelated Unity Catalog OSS v0.6.0 deployments, with the same DuckDB and extension versions on both.

## Reproduction

```sql
LOAD httpfs; LOAD delta; LOAD unity_catalog;

CREATE OR REPLACE SECRET s (
TYPE unity_catalog, TOKEN 'not-used',
ENDPOINT 'http://localhost:8080', AWS_REGION 'us-east-1'
);

-- Succeeds. No warning, no error.
ATTACH 'unity' AS u (TYPE unity_catalog, SECRET s, DEFAULT_SCHEMA 'does_not_exist');

-- Catalog metadata is fully correct:
SELECT count(*) FROM duckdb_schemas() WHERE database_name = 'u'; -- 7
SELECT count(*) FROM duckdb_tables() WHERE database_name = 'u'; -- 12

-- First actual read:
SELECT count(*) FROM u.dbt_dev.mart_daily_revenue;
```

```
INTERNAL Error: Parent catalog does not have a __internal_delta_ccv2_commit_staged function

Stack Trace:
delta.duckdb_extension(+0xdb370b)
delta.duckdb_extension(+0xdb37c4)
delta.duckdb_extension(+0xdb59e1)
delta.duckdb_extension(+0x29e9d7)
unity_catalog.duckdb_extension(+0x7ac22e)
unity_catalog.duckdb_extension(+0x7c811d)
unity_catalog.duckdb_extension(duckdb::TableInformation::InternalAttach(duckdb::ClientContext&))
unity_catalog.duckdb_extension(duckdb::UCTableEntry::GetScanFunction(...))
```

## The determining factor

Same query (`u.dbt_dev.mart_daily_revenue`), only `DEFAULT_SCHEMA` changes:

| `DEFAULT_SCHEMA` | exists in catalog | result |
|---|---|---|
| `'default'` | yes | ✅ 8 |
| `'dbt_dev'` | yes | ✅ 8 |
| `'commerce'` | yes | ✅ 8 |
| `'does_not_exist'` | no | ❌ INTERNAL Error above |

Note that the schema named in `DEFAULT_SCHEMA` does **not** have to be the schema of the table being queried - any existing schema works. It only has to resolve.

Best.

Start by running the SQL reproduction with each DEFAULT_SCHEMA value, then inspect the unity_catalog entry points UCTableEntry::GetScanFunction and TableInformation::InternalAttach named in the stack trace. Trace how a missing schema reaches the delta scan path and make the failure identify the invalid DEFAULT_SCHEMA rather than reporting a misleading internal error; verify the existing-schema cases still return the expected rows.

Written by the indexing model from the issue text.