feat(agent): complete EvoAgent integration for all 6 agent roles

Migrate all agent roles from Legacy to EvoAgent architecture:
- fundamentals_analyst, technical_analyst, sentiment_analyst, valuation_analyst
- risk_manager, portfolio_manager

Key changes:
- EvoAgent now supports Portfolio Manager compatibility methods (_make_decision,
  get_decisions, get_portfolio_state, load_portfolio_state, update_portfolio)
- Add UnifiedAgentFactory for centralized agent creation
- ToolGuard with batch approval API and WebSocket broadcast
- Legacy agents marked deprecated (AnalystAgent, RiskAgent, PMAgent)
- Remove backend/agents/compat.py migration shim
- Add run_id alongside workspace_id for semantic clarity
- Complete integration test coverage (13 tests)
- All smoke tests passing for 6 agent roles

Constraint: Must maintain backward compatibility with existing run configs
Constraint: Memory support must work with EvoAgent (no fallback to Legacy)
Rejected: Separate PM implementation for EvoAgent | unified approach cleaner
Confidence: high
Scope-risk: broad
Directive: EVO_AGENT_IDS env var still respected but defaults to all roles
Not-tested: Kubernetes sandbox mode for skill execution

docs/compat-removal-plan.md

@@ -114,3 +114,53 @@ What remains is not “legacy startup debt”, but:
 - deployment consistency
 - reduction of env-dependent fallback behavior
 - sharper documentation around gateway and OpenClaw boundaries
+
+## Residual Inventory
+
+The remaining migration-related surfaces now fall into three buckets.
+
+### 1. Remove When Replaced
+
+These should not grow further. Keep them only until a concrete replacement is
+fully in use.
+
+- `backend.agents.compat`
+  - removed after the package root stopped exporting compat helpers
+
+Recommended next action:
+
+- keep future EvoAgent cutover work on explicit run-scoped constructors rather
+  than reintroducing generic workspace-loading entrypoints on `TradingPipeline`.
+
+### 2. Keep As Stable Compatibility Surfaces
+
+These still have an operational reason to exist and should be documented rather
+than treated as accidental leftovers.
+
+- `backend.main`
+  - compatibility gateway/runtime process
+  - still relevant for websocket transport and current deploy topology
+- `runs/<run_id>/team_dashboard/*.json`
+  - export/consumer compatibility layer
+- gateway-mediated websocket/event flow
+  - still the practical live event contract for the frontend
+
+Recommended next action:
+
+- keep these, but document them as intentional compatibility surfaces with
+  explicit ownership.
+
+### 3. Defer Until Topology Decisions Are Final
+
+These are real migration boundaries, but removing them prematurely would create
+churn without simplifying the current runtime.
+
+- `workspaces/` design-time registry versus `runs/<run_id>/` runtime state
+- env-dependent service fallback behavior
+- checked-in deployment docs centered on `backend.main`
+- dual OpenClaw shapes: gateway integration and REST facade
+
+Recommended next action:
+
+- revisit these only after production topology and service-routing policy are
+  frozen.