chore(acp): bump codebuddy, dimcode, dirac, grok and kilo registry pins to probed versions

[kaizhou-lab]

Summary

Scheduled ACP Registry version sync, covering two days of drift (the 2026-08-27 run did not execute; the state file's last checked tag was v2026.08.25-fbfe844). Five npx pins drifted since #934, each backed by a fresh serial ACP probe of the exact pinned version. The diff is the lock file plus the one lock-derived test assertion that embeds codebuddy's version.

backend	package	old → new	initialize	session/new
codebuddy	@tencent-ai/codebuddy-code	2.139.0 → 2.140.0	ok (protocolVersion 1)	auth required (-32000, data.category: auth)
dimcode	dimcode	0.3.20 → 0.3.21	ok (agentInfo version 0.3.21)	auth required (-32000, "Provider credentials are required")
dirac	dirac-cli	0.4.37 → 0.5.1	ok (agentInfo dirac 0.5.1)	succeeded unauthenticated
grok	@xai-official/grok	1.0.10 → 1.0.12	ok (protocolVersion 1)	auth required (-32000, "no auth method id provided")
kilo	@kilocode/cli	7.4.23 → 7.5.5	ok (agentInfo Kilo 7.5.5)	succeeded unauthenticated

All five meet the release-lock criterion: initialize succeeds, and session/new either succeeds or returns a clearly classified authentication requirement. Probes ran serially with no inherited HOME or credentials.

dirac is the one bump crossing a minor version (0.4.x → 0.5.x), so its entrypoint was checked rather than assumed: the Registry distribution still declares dirac-cli with --acp, and that exact invocation completed initialize and opened a session advertising mode, model, and thought_level options. kilo likewise opened a session on the new minor. Neither session's catalog is persisted — per skill step 11 those columns are runtime-filled — and no metadata changes ride along with this PR.

Derived assertion updated: registry_npx_lock.rs pins codebuddy's exact version inside a --package-form argument list, so it moves with the lock — 2.139.0 → 2.140.0. Every outgoing version (2.139.0, 0.3.20, 0.4.37, 1.0.10, 7.4.23) was grepped across crates/**/*.rs before staging; codebuddy's was the only real assertion. npx_cache_repair.rs keeps its own version literals: those are cache-path hash fixtures, not lock assertions, and changing them would break their hash expectations.

The other 6 Registry-pinned packages (autohand, deepagents, glm-acp-agent, nova, pi, sigit) match the snapshot exactly. Package names and entrypoint args are unchanged for all 11. Drifted but not upgraded: none. mimo-code remains the one non-Registry builtin (no registry_json_id), excluded from drift reconciliation.

Registry snapshot

• Audit pinned to release tag v2026.08.27-ae4dcc8 of agentclientprotocol/registry, fetched via the versioned CDN path for reproducibility.
• 39 ids in the raw snapshot: no newly listed and no delisted agents versus the baseline. (antigravity-acp remains listed and deferred as binary-only since 2026-08-21; fast-agent and minion-code remain listed but uvx-only and therefore out of scope.)

Validation

• just migration-check — pass
• just lint-fix (cargo fix + clippy --fix --workspace -D warnings) — clean
• just fmt — clean
• Local cargo nextest intentionally skipped, by standing policy for lock-only bumps (established 2026-08-11). The Test check on this PR is the authority for this change: the merge decision depends on CI rather than the local run, and this host's load only manufactures timeout-shaped test failures, which nothing in the local steps above is subject to.

Logging

No logging changes: lock version bumps plus one test assertion; existing startup/session error paths already identify a failing agent by backend.