What you're hitting is expected behavior, not something you did wrong. Every materialized view is backed by a managed serverless pipeline, and that pipeline pins its catalog, target schema, and internal storage location at the moment the MV is created. A catalog rename updates the catalog entry in Unity Catalog, but it does not rewrite the config baked into an already-existing backing pipeline or its hidden materialization tables. So the pipeline keeps looking for dev_cat, which no longer exists, and you get NO_SUCH_CATALOG_EXCEPTION.

The reason your drop-and-recreate didn't fully clear it: dropping the MV is supposed to tear down the managed pipeline behind it, but when the pipeline is already in a broken state pointing at a missing catalog, the old pipeline often gets orphaned instead of cleaned up. So you end up with a fresh MV in dap_catalog_dev plus the leftover pipeline still wired to dev_cat, which is exactly the mixed YAML you're seeing (new source dataset, old pipeline name and catalog config).

To get to a clean state:

1. Drop the materialized view in the new catalog:

DROP MATERIALIZED VIEW dap_catalog_dev.caltrack.vw_item_17_electric_hourly;

2. Go to the Lakeflow / Delta Live Tables pipelines list (the managed pipelines that back MVs do show up there, they're just not created by hand). Find the orphaned pipeline whose name still contains MV-dev_cat... and delete it manually. That's the piece the drop left behind.

3. Confirm nothing else references dev_cat. Run DESCRIBE EXTENDED on the recreated objects and check the storage/location line, not just the source dataset, since the hidden materialization tables are where the stale path was hiding.

4. Recreate the MV fresh in dap_catalog_dev so a brand new backing pipeline is generated against the correct catalog name.

The broader thing worth knowing: renaming a catalog that contains materialized views or streaming tables isn't a clean operation, precisely because of these pinned backing pipelines. You can't rename a catalog in SQL at all (ALTER CATALOG has no RENAME TO), and the Catalog Explorer rename doesn't migrate the internals of MV/ST pipelines. If you have more of these to move, the safer pattern is to treat it as a recreate rather than a rename: create the MVs/STs directly in the target catalog and drop the old ones, rather than renaming the catalog out from under them.