Regression in v1.0.60: userPromptSubmitted hook additionalContext no longer injected into planner (worked in v1.0.59)

## Regression boundary

| | v1.0.59 (working) | v1.0.60 (broken) |
|---|---|---|
| Release date | 2026-06-02 | 2026-06-05 16:42 UTC |
| Our last working session | 2026-06-05 16:11 UTC (31 min before v1.0.60 shipped) | every session since |

Same machine, same plugin, same prompts. Hook behavior changed between these two versions.

## What changed

`userPromptSubmitted` hooks loaded from a plugin's `hooks.json` continue to be discovered (Copilot's startup banner shows `Loading: 8 hooks, 3 skills, 1 MCP server, 1 plugin`), but the `hookSpecificOutput.additionalContext` we return from the hook is no longer being injected into Copilot's planner.

In v1.0.59 the planner consumed the additionalContext directive and acted on it (calling the MCP tool we requested). In v1.0.60 the directive is silently dropped.

## Plugin under test

[`armoriq/armorCopilot`](https://github.com/armoriq/armorCopilot) — public, MIT.

Plugin's `userPromptSubmitted` hook returns:

```json
{
"hookSpecificOutput": {
"hookEventName": "UserPromptSubmit",
"additionalContext": "ArmorCopilot active. Call `register_intent_plan` first; step `action` = tool name, `metadata.inputs` = `{}` matches by name only.\\n\\nFor policy changes call `policy_update` (mode: replace rewrites the full ruleset; empty rules clears policy)."
}
}
```

Verified by piping a sample payload to the hook script manually — it emits this output correctly on both versions.

## Reproduction (3 prompts)

```bash
copilot plugin marketplace add armoriq/armorCopilot
copilot plugin install armorcopilot@armoriq
copilot
> show me current armorcopilot policies
> set a policy to block all web fetches
> show me the updated policies
```

**Expected (v1.0.59):** each prompt triggers `register_intent_plan` MCP tool call (because the additionalContext directive tells Copilot to). Confirmed by stderr from the plugin's MCP server in `~/.copilot/logs/`:

```
2026-06-05T16:13:51 [stderr] Capturing plan: llm=github-copilot, prompt=Show active security rules
2026-06-05T16:14:10 [stderr] Capturing plan: llm=github-copilot, prompt=Block all web fetches
2026-06-05T16:15:12 [stderr] Capturing plan: llm=github-copilot, prompt=Show active security rules
```

**Observed (v1.0.60):** `register_intent_plan` fires only on the first prompt of a new session (when Copilot does MCP tool discovery anyway). Subsequent prompts get no plan registration. Today's MCP stderr from the same machine shows a single `Capturing plan` entry per session, regardless of how many user messages.

## What still works on v1.0.60

- Plugin discovery (`Loading: 8 hooks, ...` banner)
- MCP server registration + tool calls (`register_intent_plan`, `policy_read`, `policy_update` all callable when Copilot decides to)
- Hook script execution itself — invoking it manually with the documented payload returns the right JSON

## What's broken

Just one thing: Copilot's planner stopped consuming `additionalContext` from `userPromptSubmitted` hooks. Everything else is fine.

## Workaround attempted

Downgrading via npm doesn't work — Copilot CLI's `--version` reports a runtime-fetched version that's independent of the installed npm package. Installing `@github/copilot@1.0.59` and `@github/copilot-darwin-arm64@1.0.59` still produces a binary that reports `1.0.60` and exhibits the broken behavior.

## Related

- #2540 — broader issue about plugin hooks not firing in some configurations. This is a more specific regression in the same area.

## Environment

- Copilot CLI: 1.0.60 (last working: 1.0.59)
- OS: macOS 25.5.0
- Shell: zsh
- Node: v25.8.1
- Plugin install source: marketplace `armoriq/armorCopilot`