fix(channel): reuse stored credentials when re-enabling a plugin

[szafranski]

Problem

A channel plugin (Telegram, Lark, …) can be enabled once but never re-enabled after being disabled. The Settings re-enable toggle sends an empty config {} (the token only lives in renderer state and is not re-typed), and enable_plugin rejected it with InvalidConfig("missing field credentials"). The toggle reverted and the bot never restarted.

This is the root cause of the symptom reported in iOfficeAI/AionUi#3153.

Fix

Resolve the effective config before starting the plugin: when an enable request carries no credentials, fall back to the previously persisted (encrypted) config instead of failing. Configs that do carry credentials are still validated as before, so genuinely malformed input is still reported as InvalidConfig.

• enable_plugin now resolves the config via config_with_credentials (returns the supplied config only when it carries credentials) and load_stored_config (decrypts the persisted config to reuse).
• disable_plugin already preserves the stored config row, so the credentials are available to reuse.

Tests

Added ep6_re_enable_empty_config_reuses_stored_credentials (enable → disable → re-enable with {} → plugin running, stored token reused). Verified it fails before the fix (InvalidConfig("missing field credentials")) and passes after.

• cargo test -p aionui-channel → 27 passed
• cargo nextest run -p aionui-channel -p aionui-app → 1177 passed
• cargo clippy --workspace -- -D warnings → clean
• cargo fmt --all -- --check → clean

Logging

No new logs: the success path already emits info!(... "plugin enabled and started"), and the no-stored-config failure surfaces as InvalidConfig (logged by the route's warn!). Existing observability is sufficient.

Related

iOfficeAI/AionUi#3153 — the companion renderer PR surfaces the previously-silent failure in the UI.

[szafranski]

Small coordination bump: this still looks like the backend half of the channel re-enable fix described in iOfficeAI/AionUi#3153. The UI side can surface failures more honestly, but the actual "disable -> re-enable without retyping credentials" path still depends on this AionCore change reusing the stored encrypted config.

When preparing the next coordinated release, could we make sure this is bundled with the UI-side work so the Settings toggle behavior is fixed end-to-end? Thanks!