DDL operations failing due to stale internal database UUID after dropping default database in MotherDuck account

Hi MotherDuck team, I'm hitting an issue where every DDL operation on my account fails with a stale internal database UUID, even from your web SQL editor. Account email: ggnicolau@gmail.com What happened: I had two databases on my account: `my_db` (the auto-created default) and `lakehouse` (where my actual project lives). The `my_db` only contained one legacy table from an old migration. To clean up, I dropped `my_db` entirely via `DROP DATABASE my_db`. I also dropped the empty `main` schema on `lakehouse` since it was unused. Both DROPs succeeded without warnings. The problem: Now any DDL operation — including in your own web SQL editor — fails with: Catalog Error: SET schema: No catalog + schema named "MD_DB_F881621A_70D7_4EBB_8910_730AEF2F3633.main" found. That UUID (MD_DB_F881621A_70D7_4EBB_8910_730AEF2F3633) is the internal ID of the original `my_db` I dropped. The account's default database pointer still references that UUID even though the database no longer exists. What still works: - SELECT queries against existing tables in `lakehouse.raw.*`, `lakehouse.bronze.*`, etc. — bypass the SET schema init - SHOW DATABASES, REFRESH DATABASES, basic introspection What does NOT work: - CREATE SCHEMA (any database, any name) - CREATE TABLE (suspect — haven't tested yet) - Any operation that triggers the implicit `SET schema` during session init Reproduction: 1. Open https://app.motherduck.com → SQL editor 2. Run: `CREATE SCHEMA IF NOT EXISTS lakehouse.main;` 3. Error appears as above What I tried: - Recreated `my_db` via `CREATE DATABASE my_db`. The new `my_db` got a fresh UUID, but the default pointer still references the old UUID. SELECT operations started working after this, but DDL still fails. - `REFRESH DATABASES;` — no effect on the stale pointer. - Tried connecting from local DuckDB Python client with various connection strings (`md:`, `md:lakehouse`, ATTACH with alias) — same error since it's server-side. What I need: Please reset the default database pointer for my account to point to a valid database. `lakehouse` is the one I actively use and would be a fine new default. Alternatively, point it to the newly-recreated `my_db` if that's simpler. Context for the broader picture (if useful for your team's bug triage): The fact that `DROP DATABASE` succeeded silently on the account's default database without either (a) refusing the operation or (b) updating the default pointer to another database feels like a footgun. A future check on `DROP DATABASE` that warns/refuses when the target is the account default would prevent others from hitting this. Happy to provide additional diagnostics if needed. Thanks for the help. Best, Guilherme Nicolau ggnicolau@gmail.com