[BUG] ServerPlugin implementing no plugin type interface is silently never started or stopped

[ggiannola]

Describe the bug

A server plugin whose class implements ServerPlugin but none of the eight plugin type interfaces is loaded and instantiated, but never registered. As a result its start() and stop() methods are never called, and it is invisible to the other consumers of the plugin list.

I noticed this while working on #120 (PR #397) and am raising it separately rather than changing the behaviour there, since it may well be intentional.

Details

DefaultExtensionController.initPlugins() instantiates each configured server class and casts it to ServerPlugin, then adds it to the serverPlugins list from inside a series of instanceof branches. The types checked are:

• ServicePlugin
• ChannelPlugin
• CodeTemplateServerPlugin
• DataTypeServerPlugin
• ResourcePlugin
• TransmissionModeProvider
• AuthorizationPlugin
• MultiFactorAuthenticationPlugin

If a plugin class matches none of these, no branch runs, so nothing adds it to serverPlugins. Because startPlugins() and stopPlugins() iterate that list, such a plugin is never started or stopped.

This also affects two other consumers that iterate getServerPlugins():

• AlertWorker collects AlertActionAcceptor implementations from the list. AlertActionAcceptor does not extend ServerPlugin, so it is a marker added onto a plugin class. A plugin implementing ServerPlugin and AlertActionAcceptor, but none of the eight types above, would never receive alert actions.
• DefaultUsageController reports plugin usage from the same list, so the plugin would be missing from usage statistics.

Expected behavior

Either:

1. A plugin implementing ServerPlugin is registered and gets start() / stop() called, regardless of which type interfaces it implements; or
2. If implementing at least one type interface is a deliberate requirement, the plugin is rejected with a clear log message rather than silently loaded and ignored.

Actual behavior

The plugin is instantiated with no error and then silently ignored: never started, never stopped, and absent from AlertWorker and usage statistics.

Additional context

I have not been able to confirm whether any real plugin is shaped this way, so the practical impact may be nil and this could simply be an undocumented constraint. Flagging it because the silent-ignore path makes it awkward to diagnose from the outside.

Relevant code: DefaultExtensionController.initPlugins(), startPlugins(), stopPlugins(), and AlertWorker's constructor.

[jonbartels]

This is odd but not blocking.

I agree that a plugin that doesn't fit a constraint should get a warning at runtime.

Personally, I would not accept a PR that radically changed the behavior. However a PR that adds a runtime warning or ideally a compile time error would be reasonable. Just something to warn the plugin developer that their dev process, build process, etc. didn't do the right thing.