Prevent configuration conflicts on first-time legacy plugin installs

On the reported 2026.9.5 path, legacy plugin kind inspection could invoke register(), which wrote configuration before the installer wrote the enabled flag. Optimistic config-hash locking then rejected the install, leaving settings present but the plugin disabled until a second attempt.

Passes validation mode through the existing plugin report parameters so the loader reads the legacy kind without calling registration. Ordinary diagnostics retain their existing registration behavior; no new loader, retry, or configuration writer was introduced.

• Allows affected legacy plugins to finish a first install without a competing registration-time config write.
• Preserves plugin kind detection, exclusive-slot selection, post-install registration, and existing user settings.
• Requires no configuration or storage migration and keeps the existing installation architecture.

• A source-built CLI and isolated Gateway reproduced the original config-hash conflict with a synthetic config-writing legacy plugin. After the fix, that plugin and two controls installed successfully; forced reinstall preserved the setting.
• The consolidated regression failed on the original registration path and passed after the fix. The final slot and inspection suites passed 53 focused tests; scoped lint, formatting, and source-size checks passed.
• An isolated Linux/arm64 updater test installed the candidate package over the published 2026.9.5 release, preserved the legacy plugin entry, slot, install record, and setting, then completed a new config-writing install and forced reinstall. The verified merge commit credits Goutam Adwant.
• The proof used synthetic plugins and no production credentials, reporter plugin, service restart, or cross-platform upgrade matrix. Several hosted CI shards and the aggregate gate failed, so the full PR check suite was not green at merge.