#9909: Gateway: add HITL approvals integration

## Summary - Add a typed HITL.sh client + request/response parsing and a reusable webhook payload parser. - Add a gateway callback endpoint (`/hitl/callback/<secret>`) to resolve approvals via HITL webhooks. - Gate outbound side-effects and opt-in plugin HTTP routes behind HITL approvals, with allowlists + secure-by-default failure behavior. ## Test plan - `pnpm test -- src/gateway/hitl-http.test.ts src/infra/hitl/types.test.ts` <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR introduces a Human-in-the-Loop (HITL.sh) approvals integration: - Adds typed HITL client + request/response/webhook payload parsing, an in-memory approval manager, and a persistent allowlist store. - Enforces HITL gating at the outbound delivery choke point (`deliverOutboundPayloads`) with fail-closed behavior when HITL is required but unavailable. - Adds a gateway callback endpoint (`POST /hitl/callback/<secret>`) to resolve pending approvals based on HITL webhooks. - Extends plugin HTTP routing to require gateway auth by default, with opt-in per-route HITL approval and `public: true` escape hatch. The main functional issue found is in plugin HTTP auth: the request handler passes the same Bearer token into both `connectAuth.token` and `connectAuth.password`, which can blur semantics when `gateway.auth.mode` is `password`. See the inline comment for details. <h3>Confidence Score: 3/5</h3> - This PR is close to mergeable but has an auth-mode bug that should be fixed first. - Most changes are additive and covered by tests, but the plugin HTTP auth change mixes bearer token and password fields in a way that can alter security semantics when `gateway.auth.mode` is set to `password`. Fixing that should make the integration low-risk. - src/gateway/server/plugins-http.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->