feat: add code-driven plugin config layer

[zhongxuanwang-nv]

Overview

Adds a code-driven plugin configuration layer: a host application can supply a PluginConfig programmatically that is merged on top of the file/CLI-resolved plugin config before validation and activation. This lets code apply programmatic overrides while still honoring operator files for everything it does not set.

• I confirm this contribution is my own work, or I have the right to submit it under this project's license.
• I searched existing issues and open pull requests, and this does not duplicate existing work.

Details

What changed

• Core (crates/core/src/plugin.rs) — two additive, Rust-only public functions:
  • set_code_driven_plugin_config(Option<PluginConfig>) — set/clear the layer.
  • apply_code_driven_plugin_config(&PluginConfig) -> Option<PluginConfig> — returns Some(effective) (the layer merged over the argument) when a layer is set, else None.
  • initialize_plugins applies the layer at entry (apply_code_driven_plugin_config(&config).unwrap_or(config)); the existing validate / replace-with-rollback / store flow runs on the effective config, so active_plugin_report() reflects what's actually active. The merge helper is private.
• Precedence — the code-driven layer is the highest-precedence source and overrides file/CLI config field-by-field. The merge mirrors the documented file merge: components keyed by kind (base order preserved, overlay-only appended), component config objects deep-merged (nested tables recurse, arrays/scalars replaced); top-level version/policy come from the layer.
• Doctor (crates/cli/src/doctor.rs) — reports a Plugin config source check (code-driven layer vs. file/CLI), attributes validation diagnostics to the effective config, and runs exporter sub-checks against the merged config. Output is byte-identical when no layer is set.
• Docs (plugin-configuration-files.mdx) — documents the layering model, a Rust example, the precedence ordering, and the conflict-case table.

Why
Allow code-driven plugin config to layer with materialized plugins.toml config without breaking discovery/merge semantics, and let nemo-relay doctor show the effective config source. The code-driven layer is merged then validated, so it never bypasses validation.

Constraints honored

• No changes to existing public APIs, signatures, or behavior (the two new functions are purely additive; unset layer → identical behavior).
• No changes to internal structs/datatypes (one module-level static; merge returns the existing PluginConfig).
• No language binding changes (Python/Node/WASM/FFI/Go untouched — the new API is Rust-only).

How tested

• cargo test --workspace (0 failed), cargo clippy -- -D warnings (core + cli), cargo fmt --check.
• New tests: a pure merge unit test; an isolated [[test]] binary (plugin_layer_tests.rs) for the set/apply + initialize_plugins wiring (process-isolated to avoid global-state races); two doctor tests (file+layer and layer-only).

Breaking changes
None.

Where should the reviewer start?

crates/core/src/plugin.rs — apply_code_driven_plugin_config + the one-line initialize_plugins change + the private merge_plugin_config_layers. Then crates/cli/src/doctor.rs (collect_observability_layered) for the effective-source reporting.

Related Issues: (use one of the action keywords Closes / Fixes / Resolves / Relates to)

• Relates to relay-183 (internal ticket; GitHub issues are disabled on this repo)