fix(plugin-ext): stop stale plugin host RPC protocols from hijacking replies

[dr14-make]

What it does

Fixes #17924, which has the full mechanism and the prior reports.

After the frontend reconnects, a disposed RPCProtocolImpl keeps answering the plugin host. createServerRpc discarded its HostedPluginWatcher.onPostMessageEvent disposable, and that watcher is a singleton outliving every connection with a constant pluginHostId, so the dead protocol keeps receiving. Emitter dispatch is FIFO, so it answers from an empty locals map before the live protocol does and wins the reply race — every main-side call from the plugin host fails. The plugin host then reports each failure through PluginLogger, whose $log is an RPC request whose rejection was dropped, so the unhandled-rejection reporter logs through the same broken channel and one failed log becomes thousands per second.

• hosted-plugin.ts — dispose the subscription and close the channel with the protocol, announcing the close first so in-flight requests are rejected rather than left pending.
• logger.ts — swallow the $log rejection, so a log failure cannot report itself.
• rpc-protocol.ts — report messages handled after disposal as ConnectionClosedError; an emptied locals map otherwise reads as a missing service registration.

How to test

npm test --workspace @theia/plugin-ext. Two new specs, and I confirmed each fails with its half of the change reverted rather than assuming it:

• hosted/browser/hosted-plugin-rpc.spec.ts pins the reply race. It wires a plugin host to createServerRpc through a shared watcher, serves one request, disposes that connection, opens a second, and asserts the answer comes from the live protocol. Against the pre-fix createServerRpc it fails with expected 'first connection' to equal 'second connection' — the disposed protocol answering first.
• common/rpc-protocol.spec.ts covers the post-disposal error, the in-flight rejection on channel close, and the logger no longer leaving an unhandled rejection.

Worth noting from writing that first test: with the subscription disposal alone reverted the test still passes, because closing the channel already stops delivery. The two teardown steps overlap — the subscription disposal is what stops the listener accumulating per reconnect, the channel close is what stops a disposed protocol receiving.

Manually, with the default frontendConnectionTimeout: suspend and wake the machine on an Electron app with plugins active. Before, the log fills with paired no local service handler with id LoggerMain messages at an accelerating rate and the application stops responding; after, they are gone and it stays responsive.

Follow-ups

Recorded in #17924 rather than here: the teardown also leaves the plugin session unusable (the plugin host is re-forked, so extensions lose their state, while main-side registries keep the previous connection's registrations), and it only happens at all because the default frontendConnectionTimeout: 0 makes a successful reconnect impossible. Also unexplained there: a duplicate-reply stream that survives this fix.

Two smaller ones: PluginWorker leaks its worker.onmessage/onerror wiring the same way and never terminates the Worker; and ConnectionClosedError.is() can never match a received error, because msgpackr carries name/message/stack but not the custom code.

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

HostedPluginSupport.initRpc and createServerRpc take an additional toDisconnect: DisposableCollection, matching how the rest of the file passes it around. Both are protected: a subclass that calls them no longer compiles, and one that overrides createServerRpc with the old signature still compiles but silently misses the teardown. The alternative that avoids the break is a composite disposable covering subscription, channel and protocol so the existing toDisconnect.push(rpc) carries all three — happy to switch.

Attribution

Parts of this change and its investigation were produced with AI assistance. I have read and verified every line of the diff, reproduced the bug and the fix myself, and am accountable for the contribution.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines
• User-facing text is internationalized using the nls service (for details, please see the Internationalization/Localization section in the Coding Guidelines)

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines