Use the MCP tool title as approval copy without destructiveHint

[Abhishek-B-R]

Summary

An MCP tool's title annotation only became its approvalDescription when the tool also declared destructiveHint: true. So a truthfully additive tool gated by a require_approval policy showed Approve <address>? (matched policy: <pattern>) instead of its title, and the only way to get a readable prompt was to mark the tool destructive.

This takes option 1 from the issue: the title is used as approvalDescription whenever it is present, in both toToolDef (the stored tool row) and resolveAnnotations (what enforceApproval reads at invoke time). requiresApproval is still decided by destructiveHint alone, a destructive tool without a title still falls back to its tool name, and an untitled non-destructive tool keeps the address and policy prompt.

One visible difference: for a titled non-destructive tool the prompt no longer includes the matched policy pattern, same as titled destructive tools today. The arguments preview is still appended.

Linked issue

Closes #2074

Verification

Added a create_titled tool (destructiveHint: false, title: "Create dataset") to the annotations test server and two cases in plugin.test.ts:

• the listed tool has requiresApproval: false and approvalDescription: "Create dataset"; an untitled destructive tool still reads its name, and an unannotated tool has no description
• with a require_approval policy on the integration, invoking the additive tool elicits a prompt that starts with "Create dataset"

Both fail on main (the second shows the Approve tools.annotations_test... prompt from the issue) and pass here.

• oxfmt --check on the changed files: clean
• oxlint -c .oxlintrc.jsonc --deny-warnings packages/plugins/mcp and bun run lint:changelog-stubs: clean
• tsgo --noEmit in packages/plugins/mcp: exit 0
• vitest run in packages/plugins/mcp: 312 passed, 29 skipped (39 files)
• e2e: not run; the change is covered by the plugin tests above

Checklist

• Added a changeset (bun run changeset), or this change needs none.
• Added or updated tests for the new behaviour.
• No secrets, credentials, or private data in the diff.