feat(providers): add local ZCode ACP backend

[megamen32]

Summary

• add a local zcode provider that invokes the authenticated ZCode app-server over its native framed stdio protocol
• expose ZCode in the provider, CLI and ACP-discovery catalogs without storing Z.ai credentials
• return OpenAI chat-completion and buffered SSE responses

Validation

• node --import tsx/esm --test tests/unit/zcode-executor.test.ts tests/unit/zcode-protocol.test.ts tests/unit/zcode-provider.test.ts (5 passing; isolated DATA_DIR)
• focused ESLint for ZCode, provider, ACP and CLI-catalog files
• live canary on the maintained deployment: zcode/glm-5.2 -> provider zcode, HTTP 200

Scope

• 14 files; no unrelated upstream repair commits
• ZCode app-server uses its native framed stdio protocol, so it is catalogued as a local CLI/provider but is not marked ACP-spawnable.

Upstream note

The base currently imports a missing open-sse/config/providers/registry/github/models/index.ts; that independent base defect prevents loading the full global registry in this checkout and is deliberately not included in this feature PR.

[diegosouzapw]

Thanks for this — nice, self-contained addition. I reviewed the diff and validated it independently:

• Ran your three new test files myself in a clean checkout: all 5 pass.
• Ran a focused ESLint pass on every touched file: clean, no warnings.
• Ran tsc --noEmit scoped to the touched files: clean.
• Checked the failing dast-smoke CI job — confirmed it's the pre-existing base defect you flagged in the PR description (missing github/models/index.ts), unrelated to any file in this PR.
• Traced the src/lib/acp/registry.ts addition all the way through: since AcpManager.spawn()'s hardcoded allowlist doesn't include zcode and nothing under src/app actually calls it, registering zcode there is safe — it only feeds the installed/version-probe UI, never a real ACP spawn attempt against a non-ACP process. Good call marking acpSpawnable: false in cliTools.ts to keep that boundary explicit.

The provider/executor/no-auth registration mirrors the existing auggie pattern closely, error handling goes through buildErrorBody/sanitizeErrorMessage as required, and the child-process spawning avoids shell interpolation entirely (array args, shell: false) — solid security posture for a local-CLI passthrough.

One thing worth being aware of going forward (not blocking): stream: true currently buffers the whole ZCode turn before emitting a single SSE chunk, so a client with an aggressive idle-timeout could disconnect before a long turn (up to your 120s default) finishes. You already disclose this in the CLI tool notice, which is the right call for v1 — just flagging it in case a follow-up wants true incremental streaming later.

No mandatory changes from my side. Looks merge-ready.

[diegosouzapw]

Validated in local merge-train .claude/worktrees/merge-train-20260816-000002-suite.log on devbox-vm-06-dev002 @ 8be62df65f61cc4cf29cdc3e6bc38173ffafa4e3 (FAST gates green: static + changed tests + vitest; daily full-suite run still required). Merged under the batch merge-train protocol (merge-gates §7). ⚠️ base-red inherited: #10523 (ServiceSupervisor order-dependent test, not touched by this batch).