feat(opencode): route syntax-shaped queries to ast-grep tools when available

[donbowman]

Summary

codesearch matches text, not code structure. The OpenCode plugin now adds one routing line to its injected guidance (and one alternative line to the block-mode grep denial) naming ast-grep tools such as ast_grep_search / ast_grep_edit — only when the request's tool map actually contains them.

ast-grep is not a codesearch dependency and users are not expected to have it installed. Every mention is gated on astGrepToolNames(event.tools), the assembled per-request tool map that is only visible in the context hook, so:

• environments without an ast-grep integration see unchanged guidance and denial messages;
• block mode never denies grep while pointing at a tool that does not exist;
• no one is told to call tools they do not have.

Tests

• test/unit.ts — astGrepToolNames detection: absent/null/non-object maps, non-ast-grep tools, ast_grep_* and ast-grep_* names, tool-map order.
• test/smoke.ts — guidance omits ast-grep without it and names it with it; the block denial omits it for sessions that never exposed it and names it otherwise.
• npm test (typecheck + unit + smoke) is green; the gating smoke assertion was verified to fail with the gate removed.

A CHANGELOG entry is included under the pending heading.

[flupkede]

Clean addition — the availability-gating is exactly the right discipline (nothing to install, no phantom tools, block mode only names callable tools), and the negative-tested gate is the kind of proof this plugin's warnings channel deserves.

One wording caveat, non-blocking: the guidance line reads "For syntax-shaped queries and multi-file mechanical rewrites, prefer the ast-grep tools". The second half is squarely ast-grep territory (we have no rewrite capability and don't want one — that's the agent's job). But "syntax-shaped queries" invites routing query traffic away from codesearch: "which call sites use X" is find_impact's precise answer, and concept/symbol queries belong to codesearch search. Suggest narrowing the line to the rewrite case ("For multi-file mechanical rewrites, prefer ...") — or keeping queries in but explicitly deferring to find_impact first.

For context: we're considering native structural-pattern search (ast-grep-core as a library, no external install) as a future codesearch tool — if that lands, the guidance gains a codesearch-first line and this gate composes naturally (external ast-grep remains the rewrite path). Not a dependency of this PR; merging it as-is is fine.