feat(plugins): allow daemon API opt-out

[IEatCodeDaily]

Summary

• add a backward-compatible daemonApi plugin manifest flag, defaulting to true
• skip the plugin's internal daemon session and lazily avoid loading @getpaseo/client when daemonApi is false
• keep plugin RPC handlers available; accessing handler-context paseo fails explicitly when opted out
• document the manifest option and cover the real forked worker path

Motivation

Every plugin worker currently creates a full DaemonClient session even when its server handlers never use context.paseo. That makes RPC-only plugins receive the daemon's global agent stream and retain the full client-side session state.

This showed up under active agent traffic as unrelated RPC-only workers growing together from roughly 186 MiB RSS each to more than 700 MiB. A three-run production-build probe against the emitted plugin-process.js measured an idle worker at:

Manifest	Mean worker RSS
default / daemonApi: true	166,685 KiB (162.8 MiB)
daemonApi: false	60,709 KiB (59.3 MiB)

That is a 103.5 MiB (63.6%) baseline reduction before accounting for the avoided stream growth.

The opt-out is explicit so existing manifests and plugins using the server-side PaseoApi retain current behavior.

Test plan

• npx vitest run packages/server/src/server/plugins/runtime.posix.test.ts --bail=1 — 23 passed
• npx vitest run packages/server/src/server/plugins/plugin-paseo-api.e2e.test.ts --bail=1 — 2 passed
• npm run build:server
• pre-commit npm run lint, formatting checks, and typechecks for all workspaces

[boudra]

Thanks for the report and the memory measurements. Closing this in favor of #4470, which makes the client advertise its supported protocol optimizations by default and keeps timeline and catalog traffic subscription-driven. We prefer to make the default connection lean rather than add a daemonApi manifest flag.

#4470 is still under validation and has not merged. The separate SDK import-memory cost remains outside its scope.