feat(codex-app-gateway): real buildConfig — fetch connected executors + mint per-thread cap tokens - #81

Closes the last gap in the codex-gateway end-to-end chain. Replaces the documented Phase-1 stub in `NewServer`'s `buildConfig` with a real implementation. Spawned `codex app-server` subprocesses now actually receive `[mcp_servers.exe_]` entries, so the LLM sees `mcp__exe___shell` tools.

What's in here

• New `internal/codexappgateway/captoken`: HMAC cap-token mint (matches the format codex-exec-gateway's `auth.go` verifies). The cross-service round-trip test imports `codexexecgateway.VerifyCapabilityToken` to lock the contract — so any future drift on either side fails CI.
• New `internal/codexappgateway/execgwclient`: HTTP client for `GET /api/exec-gateway/connected` with shared-secret bearer auth.
• `buildConfig` now: fetches executors per (workspace, thread) from exec-gateway, mints one single-exe-id 24h cap token per executor (threadID as audit/revoke key), populates `ConfigInput.Executors` so `RenderConfigTOML` produces the right `[mcp_servers.exe_*]` entries.
• `ConfigBuilder` closure now takes `ctx context.Context` (4 test files updated for the new signature).
• Integration test `TestBuildConfig_FetchesAndMintsCorrectly` stands up a fake exec-gateway, runs buildConfig end-to-end, asserts each minted token verifies via the real exec-gateway verifier and the rendered `config.toml` has the right MCP server sections.

End-to-end chain after this PR

```
TUI codex --remote
→ codex-app-gateway (HMAC auth)
→ spawn codex app-server subprocess (with REAL [mcp_servers.exe_*] config) ← this PR
→ spawn env-mcp child per executor (PR #78)
→ ws bridge to codex-exec-gateway (PR #80)
→ real codex-exec on user's laptop
```

Test Plan

• `go test ./internal/codexappgateway/...` — all PASS (added 7 new tests across captoken/execgwclient/buildconfig)
• `go test -race` — clean
• `go vet` — clean
• `go build` — clean
• Cross-service contract test `TestMint_VerifyRoundTrip` — Mint here, Verify in codex-exec-gateway, all fields match. PASSES. This locks the cap-token format on both ends against future drift.
• End-to-end test `TestBuildConfig_FetchesAndMintsCorrectly` — fake exec-gateway returns 2 executors → buildConfig produces 2 entries with correct ExeIDs / BridgeURLs / TokenEnvs / verifiable cap tokens / RenderConfigTOML output. PASSES.
• Reviewer: with a real DB + the real codex-exec-gateway running, mint an executor token, run `codex exec-server --remote ws://exec-gw/codex-exec/{exe_id} --executor-id {exe_id}` from a separate process, run `codex --remote ws://app-gw/codex-app/...` from another process, send a prompt that needs shell — confirm the shell call routes through env-mcp → bridge → real codex-exec.

Spec / Plan

• Spec: `docs/superpowers/specs/2026-05-10-codex-app-gateway-subprocess.md` (the "buildConfig phase-1 stub" was explicitly listed in Open Risks Admin dashboard #1)
• The closure flow + cap-token format are documented in `docs/superpowers/specs/2026-05-10-codex-gateway-mcp-rewrite.md` § Subsystem 2 + § Subsystem 3 cap-token

Follow-ups (deferred, not blocking)

• Invoke `POST /api/exec-gateway/revoke-turn` on subprocess shutdown to invalidate cap tokens before their EXP. Currently relies on EXP only (24h).
• Hardcoded `ModelProvider=modelserver`, `Model=gpt-5.5`, `BaseURL=http://llmproxy:8085/v1\` in `buildConfig` should come from `Config` (env-vars) rather than being inline. Trivial follow-up.