fix(plugin-loader): deliver stored config to freshly-started plugin workers (LOOA-629)

[nguyenm7]

Summary

The Slack chat gateway (LOOA-629) came up inert (slackEnabled:false, pollEnabled:true) even after the plugin reached status: ready and its worker spawned on the fixed build. Root cause: the worker never receives its config.

A plugin worker is spawned once per plugin with an empty bootstrap config and is expected to read company-scoped config via ctx.config.get(companyId). Governed access (packages/plugins/sdk/src/host-client-factory.ts) only resolves that call inside a company-scoped invocation (event/action/tool, or params.companyId). A proactive plugin like the chat gateway does its company work from setup() (opens a Slack Socket Mode connection, starts loops) — there is no invocation scope there, so config.get() is rejected with company context is required, the worker swallows the error, and falls back to its default (Slack-off) config.

This is a regression from paperclipai#9557 ("governed access contracts", 1de0a3bb1), which changed plugin-loader.ts activatePlugin from loading the stored config into the worker bootstrap to const config = {}.

Evidence (host server.log, gateway enable at 15:19:48Z):

ERROR host handler error {method: "config.get"}
  err: 'Plugin "52ea4d0a…" is not allowed to perform "config.get": company context is required'
ERROR [plugin] gateway: failed to read config

The Slack config is present and correct in plugin_config for the target company — it just never reaches the worker.

Fix

After the worker starts in activatePlugin, replay each configured company's config through the same configChanged path an operator config-save uses (server/src/routes/plugins.ts). configChanged is a host→worker call (not scope-gated); onConfigChanged handlers are idempotent for well-behaved plugins, so replaying an unchanged config is safe. Best-effort — a worker without onConfigChanged, or one momentarily unavailable, simply keeps the runtime ctx.config.get(companyId) model. Covers both server-boot loadAll and operator plugin enable.

• plugin-registry.ts: add listConfigs(pluginId) (reads all company config rows).
• plugin-loader.ts: replay stored config to the freshly-started worker.
• test: DB-backed coverage for registry.listConfigs.

Testing

• server tsc --noEmit: clean.
• New plugin-config-startup-delivery.test.ts (embedded-postgres, 3 cases): pass.

Notes / follow-ups

• For plugins configured across many companies, this fans out one configChanged per company at startup (matches operator-save semantics). Fine for the gateway; a batched delivery is a possible future optimization.
• A full activatePlugin integration test asserting the push is a good follow-up (no isolated harness for it today; the push mirrors the already-shipped operator-save path).
• Go-live is operator-gated: pull to the host + restart (or re-enable the gateway) to pick up the fix.

🤖 Generated with Claude Code

[nguyenm7]

Superseded by paperclipai#10092 — the operator pulls from origin (paperclipai/paperclip), so the fix must target upstream master, not the fork.