Add signing_keypair (Ed25519) provisioner type — required for #228 / git-mcp signing

[chitcommit]

Context

Surfaced by chico-keys while attempting to action #228 (git-mcp credential provisioning).

The Git Tool Surface spec (#208/#209) requires Ed25519 signing keys for /api/v1/signing/sign-commit and /sign-tag handlers. Per #228 operator decisions:

• Algorithm: Ed25519
• Scope: broker-wide single signing key ("broker holds key" is canon)
• Rotation: 365d
• Mint path: server-side via credential-provisioner — operator never paste/handle/copy key material

Gap

The current EnhancedCredentialProvisioner (src/services/credential-provisioner-enhanced.js) registers these types only:

• cloudflare_token
• service_token
• github_token
• neon
• integration_api_key

There is no signing_keypair / asymmetric keygen type, and no standalone credential-provisioner worker is registered in ChittyRegistry or reachable at credential-provisioner.chitty.cc / provisioner.chitty.cc.

The legacy 1password-connect-client.js is marked DEPRECATED in CREDENTIAL_PROVISIONING.md (canonical path is now CF Secrets Store synced from synthetic-shared vault via sync-secrets.sh). It is not the correct extension surface.

This blocks #228 on the credential-mint step. Operator-paste fallback is forbidden by the sensitive-intent contract.

Ask

Add a signing_keypair provisioner type to EnhancedCredentialProvisioner with:

1. Server-side Ed25519 keypair generation (Web Crypto crypto.subtle.generateKey({name:'Ed25519'}) — Workers runtime supports this on nodejs_compat).
2. Private key write into 1Password synthetic-shared vault via the canonical sync path (NOT the deprecated 1P Connect runtime client) — item naming: <service>-<purpose>-ed25519-<env> (e.g. chittyconnect-git-signing-ed25519-prod).
3. CF Secrets Store binding emitted so workers read env.GIT_SIGNING_PRIVATE_KEY directly (zero-latency canonical path per CREDENTIAL_PROVISIONING.md).
4. Public surface: key_fingerprint (sha256 of pubkey, 64-hex) — the only value exposed outside the broker. Public key exportable; private key never returned.
5. Audit event to credential_provisions D1 table (existing pattern).
6. Validation hook: provisioner returns the fingerprint reproducibly from the deployed binding (callable via debug endpoint).

Sibling: rotation runbook (365d)

File a doc-only follow-up: docs/SIGNING_KEY_ROTATION.md covering the 365d rotation cycle, dual-key overlap window for in-flight verification, and ChittyLedger event shape for rotation. Should land alongside the provisioner type so first deploy starts the clock.

Refs

• chico-keys: provision credentials for git-mcp workstream (#209, #309, #111) #228 (chico-keys ask)
• feat(mcp): spec git tool surface (read on chittymcp upstream, write on ChittyConnect) #208 / [git-mcp] Implement git_commit / git_push / git_tag handlers #209 (Git Tool Surface spec + handlers)
• feat(mcp): spec git tool surface (read on chittymcp upstream, write on ChittyConnect) chittymcp#110 / fix: concierge review — error context, header guards, log severity #111
• CREDENTIAL_PROVISIONING.md (canonical mint path)
• docs/SECRET_MANAGEMENT_ARCHITECTURE.md (synthetic-shared vault model)

Why this is concierge-filed (not actioned inline)

Per chico-keys guardrail: "If credential-provisioner worker is unreachable / missing / lacks vault scope → STOP, file follow-up, report. Do not fall back to operator-paste." Inline-extending the provisioner during a credential-provisioning task crosses lanes — it's net-new capability that needs its own review/PR cycle.