sql: per-caller usage attribution via dedicated endpoint chains

MetaMCP proxies with a fresh outbound connection and forwards no client
identity — not User-Agent, not X-MCP-Client, not initialize.clientInfo.
A downstream server that logs client identity therefore sees only
MetaMCP's own Node UA, and every client behind the gateway collapses
into one undifferentiated bucket. Verified by probe: three distinct
identity values in, {"name": "node", "user_agent": "node"} logged out.

Not patchable at reasonable cost: downstream connections are pooled and
pre-warmed (idleSessions[serverUuid] / createIdleSessionAsync), so one
connection serves many inbound callers and headers bind at connection
creation. No per-request injection point exists without disabling
pooling, re-keying the pool by (server, caller), or threading
AsyncLocalStorage through the transport.

But MetaMCP already supports static per-server custom headers —
mcp_servers.headers is jsonb and flows into the outbound
requestInit.headers. So give each caller its own endpoint → namespace →
server chain, pointing at the SAME backend URL, differing only in a
stamped X-MCP-Client header. Same container, same corpus, nothing
duplicated downstream.

Adds sql/zsupport-endpoint.sql (the worked example, applied to the live
gateway 2026-07-27 — zSupport now attributes correctly) and a README
section covering the pattern and its two gotchas: the UNIQUE (name,
user_id) constraint forcing a new server name, and the resulting change
of tool-name prefix that any client allow-list must track.

sql/** added to the workflow's paths-ignore — config, not image.

.gitea/workflows/build.yml

@@ -18,6 +18,9 @@ on:
       - "README.md"
       - "LICENSE"
       - ".gitignore"
+      # sql/ holds MetaMCP *config* (rows applied to its Postgres), which has
+      # nothing to do with the image contents — don't rebuild on those edits.
+      - "sql/**"
   schedule:
     # Every day at 08:00 UTC — pulls upstream :latest and rebuilds.
     - cron: "0 8 * * *"