Fix Web workflow engine compatibility

[FengHuoLinShan]

Summary

• resolve the workflow engine from the calling Agent's scoped context via exec.agent.ctx.workflowEngine
• keep the host-level plugin dependent only on tools, so Web can use each preset's isolated engine without mounting a second host engine
• update current DSH peer ranges, development paths, compiled artifacts, tests, and compatibility documentation

Root cause

The plugin still injected the removed workflows service and called ctx.workflows.start(). Current DSH exposes workflowEngine, while the Web composition deliberately mounts that engine inside each Agent preset rather than on the host. The host-level plugin therefore remained pending during startup.

Impact

Web profiles now activate the plugin successfully. Standard/code presets route runs through their own workflow engine; presets without that capability fail with an explicit error.

Validation

• pnpm run typecheck
• pnpm run build
• node --test (6 passed)
• git diff --check
• real dsh web --port 0 startup with the packaged plugin
• runtime probe using the installed DSH Cordis/tools stack, confirming deep_research registration and Agent-scoped workflow routing