fix(mcp): attach folder assignments through IAP and the agent gate

[syucream]

Summary

import --mcp through the n8n-cli proxy now actually attaches folder assignments (parentFolderId / folder). Two hops were missing from the existing CLI → proxy → mock stack, and both had to fail in the same way production did before the path was real.

The public REST API never returns which folder a workflow sits in, so import reads that assignment over n8n's instance-level MCP server. That MCP call left the machine through a raw fetch, while REST and webhook already ran ctx.clientMiddlewares (iap-auth, impersonator-token). Against an authenticating gateway the REST import succeeded and MCP 403'd with IAP HTML — JSON was written with no folder keys. The CLI still sends no MCP Authorization in proxy mode; the proxy injects the token on /mcp-server/*.

Fixing IAP is not enough on its own. Production n8n-proxy gates MCP for agents (N8N_MCP_ALLOW_TOOLS=search_workflows,get_workflow_entry,execute_workflow, no get_workflow_details, search narrowed to in-policy workflows). The same CLI talking through that gate still got a successful REST import and JSON with no folder keys: search omitted the untagged workflow and get_workflow_details came back Unknown tool. A verified impersonator (oauth-verify trusted Cloud Run bearer + impersonator-verify) is an operator, not an agent, so folder-read verbs (search_workflows, get_workflow_details, search_folders) skip the allowlist and the search filter for that caller. execute_workflow stays gated. A spoofed X-Impersonator-Id-Token without a verifier does not count.

The operator-identity probe runs only identity-populating middlewares. project-role and authz need a workflow this probe does not have — they would deny the lookup itself, or hit Zeus on every initialize.

Deploy: live import --mcp against current n8n-proxy also needs this proxy binary. The CLI IAP fix alone cannot attach folders while production still serves the old gate.

Bump to 2.23.0.

Motivation

#82 added folder membership as code, with import --mcp as the only read path for a write-only REST field. The proxy already had bearer-token-inject for /mcp-server/* and the CLI already had IAP egress for webhook. Neither was wired to MCP, and the existing integration tests never stood an IAP front door or a production-like agent allowlist in front of the proxy — so token-inject stayed green while production wrote JSON with no parentFolderId / folder. Teams using n8n-workflows' folder-as-code import cannot place files until this hop is the same one REST already takes, and until the agent gate does not strip operator folder reads.

Test plan

• make quality-gate (generate-schemas, typecheck, lint, check-third-party-licenses, bun test) — 1955 pass
• bun test tests/integration — CLI → [IAP] → proxy → mock, including import --mcp folder reads
• make build + size-check
• MCP egress: middlewares run on initialize / notify / tool call; proxy mode still has no MCP Bearer; a middleware throw sends nothing
• IAP stand-in rejects the CLI with no egress (HTML 403, the production failure); iap-auth + proxy inject writes parentFolderId / folder on JSON; MCP through IAP carries no MCP Authorization
• Production-like agent gate + impersonated CLI attaches folders for an untagged workflow; the same gated proxy strips them when the CLI is not impersonated (REST succeeds, search withholds the row, get_workflow_details is unknown — silent missing keys)
• Real oauth-verify + impersonator-verify: Cloud Run Bearer + impersonator token unlocks get_workflow_details; MCP Bearer does not; SA Bearer without impersonator does not; spoofed header without a verifier does not; authz that would deny a bodyless probe does not strip operator folder reads; execute_workflow stays gated