bug: 'web'/'search' tool-category aliases silently resolve to no bound tool in headless --agent dispatch

[jehubba]

Summary

When an agent's frontmatter declares tools using the category aliases web or
search, those aliases silently resolve to no bound tool at all when the
agent is dispatched headlessly via copilot --agent <name> -p ... --allow-all-tools.
There is no error or warning — the agent simply has no web-fetch/web-search
capability, which is easy to miss since nothing fails loudly.

Other category aliases in the same position work correctly: read → view,
edit → edit, shell → powershell, agent → task/read_agent/list_agents.
Only web and search are affected.

Environment

• GitHub Copilot CLI 1.0.68 (Windows)
• Invocation: copilot --agent <name> -p "<prompt>" --allow-all-tools

Repro

Agent frontmatter:

---
name: tool-probe
tools:
  - read
  - web
  - search
---

Dispatch:

copilot --agent tool-probe -p "List every tool you have available to you right now, one per line, then stop." --allow-all-tools

Observed bound tools: view, skill, sql — no web/search tool at all.

Changing the frontmatter to the literal tool names instead of the category aliases:

tools:
  - read
  - web_fetch
  - web_search

Observed bound tools: view, web_fetch, web_search, skill, sql — correct.

Impact

Any agent relying on the documented web/search category aliases for web
access has zero web tooling in headless dispatch, with no error surfaced
anywhere. We found this affected 5 of our own agent specs (including a
Chief-of-Staff-style orchestrator whose own web lookups were silently broken)
before switching to literal tool names as a workaround.

Suggested fix

Category-alias resolution for web/search should map to web_fetch/web_search
in headless --agent dispatch mode the same way shell correctly maps to
powershell and read maps to view.