Emit native session-start output for GitHub Copilot CLI hooks

[konard]

Problem

archcore hooks copilot session-start exists in v0.5.7, but it reuses the Claude Code session-start handler and emits Claude's response envelope:

{
  "hookSpecificOutput": {
    "hookEventName": "SessionStart",
    "additionalContext": "..."
  },
  "systemMessage": "Archcore v0.5.7 · MCP connected · N docs"
}

GitHub Copilot CLI's native sessionStart contract expects top-level additionalContext. Copilot logs the Claude-shaped stdout but does not add its context to the model conversation.

This is the needs-cli dependency for archcore-ai/plugin#24 and archcore-ai/plugin#26.

Reproduction

From an initialized project:

printf '%s' '{"cwd":"/tmp/initialized-project"}' \
  | archcore hooks copilot session-start

With Archcore CLI v0.5.7, the result contains hookSpecificOutput and hookEventName: SessionStart as above.

Loading the plugin with Copilot CLI 1.0.73 confirms the distinction:

• initialized project: debug output shows the Claude-shaped hook stdout once, but the Archcore context is absent from the assembled model context;
• uninitialized project: the plugin's top-level {"additionalContext":"[Archcore] no .archcore/..."} response appears in the assembled model context.

Root cause

cmd/hooks_copilot.go registers Copilot through newSessionStartHookCmd, which calls the Claude-specific handleSessionStart in cmd/hooks_claude_code.go. There is no Copilot response encoder.

Expected behavior

archcore hooks copilot session-start should preserve the shared context construction while encoding the Copilot-native response, at minimum:

{"additionalContext":"[Archcore — Git-native context for AI coding agents]\n..."}

Claude Code, Cursor, and Gemini output must remain byte-for-byte unchanged.

Acceptance criteria

• Add an exact-output Copilot session-start test that rejects hookSpecificOutput and pins top-level additionalContext.
• Keep context generation shared; add only a Copilot-specific encoder/command path.
• Verify the response is injected by a live Copilot CLI session in an initialized scratch project.
• Document Copilot's response shape in the CLI hooks reference.

Separate Copilot runtime dependency

Plugin-provided MCP servers currently start in the plugin installation directory and receive no project path. That upstream limitation is tracked in github/copilot-cli#4234; it is separate from this response-envelope fix.