[Feat] Route tasks using linked communication context

[roomote-roomote]

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• Teach the workspace router to recognize underspecified requests containing communication message or thread links as candidates for external context lookup.
• Fetch supported links through the existing authenticated, read-only Roomote chat-context MCP tools before making the final routing decision.
• Keep provider names out of the model-facing routing rules, treat fetched messages as untrusted reference material, and preserve the original task prompt.
• Bound lookups by reference count, content size, and timeout, while failing open when a link is unsupported or inaccessible.

Why this change was made

Requests such as "look into this" do not contain enough information to select an environment when their useful context lives in a linked conversation. The router should inspect that context before task creation without broadening access or leaking the fetched conversation into the task prompt.

Impact

Pasted supported communication links can now influence environment selection before a task starts. Router tests cover authenticated tool invocation, successful rerouting across multiple environments, lookup limits, unsupported links, and fail-open behavior. The router unit suite, package type checks, formatting, targeted lint, and repository pre-push checks pass; the live Promptfoo eval could not run because its external provider credential is unavailable in this environment.

[roomote-community]

1 issue outstanding. See task

• Fetch the model-selected communication link before other links (packages/cloud-agents/src/server/router/external-communication-context.ts:77-81).

_{Reviewed 4232435}

[roomote-community]

externalReference is meant to identify the exact link the precheck selected, but it is appended only after every task URL and the two-reference cap is applied during that pass. With three valid communication links where the model selects the third, this fetches the first two and never fetches the selected link, so the second routing decision is based on unrelated context. Prioritize the validated externalReference (or filter to it) before applying the cap.