Feature: Support additionalContext on Stop hooks (parity with UserPromptSubmit)

Description

UserPromptSubmit hooks can inject context into the conversation via hookSpecificOutput.additionalContext without blocking the response. Stop hooks cannot — they can only allow (exit 0) or block (exit 2).

This means any Stop hook that wants to add context to the LLM's next turn must block the current response, which silently discards the user-visible output. The LLM then re-generates, often losing or duplicating content.

Requested

Allow Stop hooks to return additionalContext that gets injected into the next turn's system context — without blocking the current response. The response goes through to the user normally, and the injected content appears on the next prompt.

For example, a Stop hook returning:

{
  "decision": "allow",
  "hookSpecificOutput": {
    "additionalContext": "Reminder: check X before proceeding"
  }
}

Would let the current response through and inject the reminder on the next turn.

Use cases

• Memory systems — inject retrieved context without eating the current response
• Linters / code review — annotate responses with warnings for the next turn
• Audit trails — log observations for the LLM to consider next time
• Style enforcement — nudge the LLM on tone/format without blocking output
• Any post-response annotation that should influence the next turn but shouldn't interrupt the user

Current workarounds

• Block + re-prompt (loses the original response, causes duplicates)
• Write a staged file, consume it in a UserPromptSubmit hook on the next turn (fragile, requires coordination between two hooks)

Both are brittle. Native additionalContext on Stop hooks would be clean parity with UserPromptSubmit.

Related

• #39499 — Silent re-prompt (different approach to the same friction)
• #35086 — Hook output display for blocking vs failure