CmdPal: dock band buttons stop working after the host releases the extension — clicks fall back to opening the palette, extension is never re-activated

Environment

• Command Palette standalone dev build 0.12.12365.0 (Microsoft.CommandPalette_8wekyb3d8bbwe)
• Windows 11 Pro for Workstations, build 10.0.26200
• Extension: an out-of-proc COM extension providing dock bands via GetDockBands() ("Virtual Desktops 2.0", built on the CmdPal extension template, Shmuelie.WinRTServer as the COM host)

Steps to reproduce

1. Install an extension that provides dock band items (each item's command executes on click).
2. Use the dock band — clicks work (desktop switching, in this case).
3. Leave the system alone for a while. At some point the host releases the idle extension: the extension receives IExtension.Dispose(), and its out-of-proc process exits cleanly (no crash entries in the Application event log — this is the normal OOP COM lifecycle).
4. Click a dock band button.

Expected behavior

The host re-activates the extension's COM class and executes the command — or, at minimum, refreshes/removes the stale band so the user isn't clicking dead buttons.

Actual behavior

The click opens the main palette window instead of running the command. The stale band keeps being rendered indefinitely, and nothing re-activates the released extension:

• dock band clicks keep opening the palette (observed repeatedly over hours);
• opening the palette and searching still shows the extension's top-level commands (served from the host's cache) even though the backing extension process is gone — Process.GetProcessesByName on the extension executable shows no process;
• the extension process is not re-spawned by any of these interactions; only restarting the CmdPal host brings the band back to life (host start → extension activated → band works again).

Notes

Idle release itself is fine — that's the normal OOP COM server lifecycle, and our server exits when the last reference is dropped. The gap is that dock bands have no re-activation path once the host has released the extension: the band UI outlives the COM object it is bound to. Either dock band clicks should trigger re-activation of the extension, or the host should drop stale bands when it releases one.

Happy to provide more diagnostics (DebugView traces from the extension, a repro build, etc.).

Trace dock-band click handling from GetDockBands() through the host's extension activation and IExtension.Dispose() lifecycle. Reproduce the issue after idle release, then verify that a click re-activates the COM extension or that the stale band is removed instead of opening the palette.