#2746 A pulled extension can shadow a built-in type, and removing it leaves serve without the built-in

Summary

A pulled extension can declare a type whose name matches a built-in type, such as the model type command/shell or a built-in vault type. The pulled type then replaces the built-in in the registry. When the extension is removed, serve cannot restore the built-in until it restarts.

Where it happens

• validateUserCollective only requires two segments, so a pulled model named command/shell is accepted. The vault, datastore, report and webhook adapters have no namespace check.
• The extension loader writes the catalog row with type_normalized even when adapter.hasType() is already true, and isOutrankedForType only compares against other catalog rows.
• The serve reload's register loop (src/serve/extension_reload.ts, reloadPulledExtensions) calls invalidateType and then registerLazy for each pulled row. That replaces the built-in entry with the pulled lazy entry.
• Since swamp-club#2742, a reload unregisters a removed extension's types when no other catalog row provides them. Built-in types have no catalog rows, so removing such an extension leaves no entry and nothing puts the built-in back. Before #2742, a stale lazy entry was left in its place, which was also broken.

Steps to reproduce

1. Pull an extension that declares model type command/shell onto a managedConfig serve.
2. After the next config poll, workflows using command/shell run the extension's code instead of the built-in.
3. Run swamp extension rm on that extension. After the next poll, command/shell is unknown on that instance until serve restarts.

Expected

A pulled extension cannot claim a built-in type name, or the built-in always wins. Removing the extension never affects built-in types.

Found by the adversarial review of swamp-club#2742. Not reproduced yet.