feat(mcp-gateway): mcpwire, the process-group compat layer, and reserved prefixes

[damonleelcx]

Snapshot of in-flight work in the pkg checkout. Three shared modules the MCP gateway needs, placed here rather than in a consumer because both the proxy and the control plane reach for them.

module	what, and why it is shared
mcpwire/	the MCP wire types — so the proxy and the control plane cannot disagree about the protocol by each parsing it their own way
aikeycompat/	procgroup, with real unix and windows implementations rather than a stub on one side. It exists because a clean child exit does not reap its descendants: an stdio-hosted MCP server that spawns helpers left them running after shutdown
providerregistry/reserved.go	the route prefixes an MCP virtual server may not take, so an MCP path cannot shadow a provider route. aikey-proxy#42 fences the same property at its router; this is the shared list both sides read

🔴 Merge order: workflow#98 must land first

mcpwire's TestUserDocsDocumentEveryErrorCodeAndInventNone reads across the repo boundary into workflow/CD/installer/quickstart-mcp-gateway{,.zh}.md — "the customer-facing error table is part of the deliverable, not an optional extra." Those two files are in workflow#98.

I hit this for real: on a clean develop-v1.0.6 base the module went red, and went green again once the sibling tree carried workflow#98's branch. Merging this before workflow#98 turns that fence red.

Verified in this session

This repo is multi-module, so per module, on the clean base:

providerregistry  ok
aikeycompat       ok
mcpwire           ok   (with workflow#98 as the sibling; red without it)

One thing deliberately left out

The local pkg checkout also carries an unpushed commit 92fcc0c wip(maskrestore): new maskrestore module — "Snapshot of in-flight work committed before switching branches." That is not part of this change and is not in this PR; it is still sitting unpushed in the local checkout for whoever owns it.

🤖 Generated with Claude Code