feat: add getToolContext method to PluginMCPEntry interface

[pikann]

Summary

Adds an optional getToolContext hook to PluginMCPEntry, so a plugin can attach additional text to the response of any core Paca MCP tool call — not just tools the plugin owns.

The motivating case: an AI agent calls get_task and gets back the task's title, status, activities, etc., but has no idea a GitHub branch or PR is linked to that task unless it separately discovers and calls github_list_task_branches. getToolContext lets the GitHub (or BDD, Checklist, …) plugin attach that info directly to the get_task response instead.

What's added

• PluginMCPEntry.getToolContext?(toolId, args, context) — called once per loaded plugin after a successful core tool call. Returns string | null | undefined; null/undefined means "nothing to add for this call" so the host omits the section instead of rendering empty boilerplate on every call.
• InstalledPlugin.manifest.mcp.toolContextHooks?: string[] — the plugin declares up front, in plugin.json, which core tool IDs it can contribute to (e.g. "toolContextHooks": ["get_task"]). The host only invokes getToolContext for plugins that declared the tool being called — implementing the method without declaring it here means it's never called. This keeps the common case (a plugin only cares about one or two tools) a cheap map lookup on the host side instead of a fan-out call to every loaded plugin on every tool call.

Usage

const entry: PluginMCPEntry = {
  tools: [ /* ... */ ],
  async handleToolCall(name, args, context) { /* ... */ },

  async getToolContext(toolId, args, context) {
    if (toolId !== "get_task") return null;
    const { projectId, taskId } = args as { projectId: string; taskId: string };

    const api = new PluginAPIClient(context);
    const items = await api.pluginGet<Item[]>(
      `projects/${projectId}/tasks/${taskId}/items`,
    );
    if (items.length === 0) return null;
    return `## My Plugin\n\n${items.map((i) => `- ${i.title}`).join("\n")}`;
  },
};

// plugin.json
"mcp": {
  "remoteEntryUrl": "...",
  "toolContextHooks": ["get_task"]
}

See the updated README for the full contract and error-handling semantics — plus the get_task_by_number caveat (its args has no taskId, only taskNumber, so a hook scoped to get_task won't fire for it). A matching write-up for docs/plugins/mcp-plugin-system.md in the main paca repo is pending in a separate PR there.

Also in this PR

• Bumps CI's node-version from 20 → 24 in .github/workflows/cd.yml (unrelated, small).

Consumers

com.paca.github, com.paca.bdd, and com.paca.checklist all implement getToolContext for get_task (branches/PRs, scenarios, and checklists respectively) — those changes ship in their own repos and depend on this SDK version.

Test plan

• tsc -p tsconfig.build.json && vite build — builds clean
• Verified end-to-end against the Paca MCP host (apps/mcp): a real agent conversation's get_task call returned a merged GitHub section for a task with a linked branch