#2742 managedConfig: extension rm on one serve instance leaves the extension's types registered on its peers

Summary

Under managedConfig, when one serve instance (or an operator CLI) runs swamp extension rm, the other serve instances keep the removed extension's types registered. They go on listing it in type search and running models of that type until they restart.

This is one of the follow-ups listed in #2612 ("Serve reload does not unregister a removed extension's types"). It is filed separately because #2612 explicitly does not delete sources or unregister types.

Where it happens

The ConfigPoller notices the change: the tier lockfile's hash changes, it logs Config poller: extension lockfile changed, reloading, and it calls performServeReload (src/serve/config_poller.ts:196-266, wired in src/cli/commands/serve.ts:2727-2769).

The reload then only works from what is still in the lockfile:

• reloadPulledExtensions (src/serve/extension_reload.ts:149-315) loops over lockfile.getAllEntries(). It invalidates and re-registers the types of extensions that are still listed. An extension that was removed is no longer in the lockfile, so its types are never visited, invalidated or unregistered.
• The extensionDiscoverer passed to the reload only adds newly found types.

Nothing in that path compares the registered pulled types with the lockfile, so a removed extension's registrations stay in the model, vault, datastore, report and webhook registries.

Steps to reproduce

1. Two swamp serve instances, A and B, on one S3 datastore with managedConfig: true and a short --datastore-poll-interval (e.g. 2s). B is started without --hot-reload.
2. swamp extension pull <ext> --server <A>. Wait for B's poll: B logs Config poller: reloaded N extension type(s) and swamp type search --server <B> lists the type.
3. swamp extension rm <ext> --server <A>.
4. Wait for B's next poll (B logs Config poller: extension lockfile changed, reloading).
5. swamp type search --server <B> still lists the removed type, and a model of that type still runs on B.

This was found by reading the source at swamp b4d6bad2. It has not yet been reproduced against a running cluster.

Expected

After a peer removes an extension, the next poll unregisters that extension's types on every instance, the same way a pull registers them. type search --server <B> stops listing the type, and running a model of that type fails with the usual unknown-type error.

Related

• #2612: converging each checkout to the shared lockfile. This bug is one of its listed follow-ups.
• #2490: catalog rows left behind after extension rm, fixed for the local checkout.
• A matching swamp-uat test, MC-E4 ("swamp serve unregisters an extension removed on a peer"), is planned as part of the managedConfig UAT coverage.