Fix sidecar server config loading

[xd4rker]

Description

This fixes an issue with SidecarPluginConfiguration not being registered as a server config bean. Its sidecar_* settings in graylog.conf were ignored and always fell back to default values.

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have requested a documentation update.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[patrickmann]

Great catch. This is a good targeted fix and we should backport it.

Consider filing a separate issue for follow-up to prevent similar issues going forward:

Title: Detect server config beans that are bound but never parsed from graylog.conf

PR #26200 fixed SidecarPluginConfiguration being ignored: its sidecar_* settings in graylog.conf were never read, and the server silently used defaults. Root cause was that the bean was bound into Guice but never registered with JadConfig, so the parsed values never reached the injected instance.

The failure was silent — there was no test and no startup check that would have caught it. The same gap applies to any PluginConfigBean, not just Sidecar.

Invariant to enforce

For every PluginConfigBean type that gets injected, the instance Guice provides must be the same instance JadConfig populated from graylog.conf. Today a bean can be bound (or JIT-constructed) without ever passing through JadConfig, in which case it silently carries field defaults.

Proposed checks:

1. Guardrail test. Build the server injector and assert that every bean in the bound Set is also present (by reference) in jadConfig.getConfigurationBeans(). This currently has zero test coverage and would fail loudly if the #26200 fix were reverted.
2. Targeted startup check. Near the end of bootstrap, diff the bound PluginConfigBean classes against the classes registered with JadConfig and log an ERROR (or fail startup) for any bean that was bound but never parsed. Self-contained; no behavior change for correctly-registered beans.

Out of scope

• Enabling requireExplicitBindings() on the main injector (separate hardening effort).
• Unifying the two registration paths (getNodeCommandConfigurationBeans() vs PluginModule.getConfigBeans()) into a single source of truth. Worth a follow-up ticket but more involved due to bootstrap ordering.