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

[kaizhou-lab]

Summary

Scheduled ACP Registry version sync. Four npx pins drifted since #963, 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.143.0 → 2.143.1	ok (protocolVersion 1)	auth required (-32000, data.category: auth)
dimcode	dimcode	0.3.27 → 0.3.28	ok (agentInfo version 0.3.28)	auth required (-32000, "Provider credentials are required")
dirac	dirac-cli	0.5.2 → 0.5.5	ok (agentInfo dirac 0.5.5)	succeeded unauthenticated
grok	@xai-official/grok	1.0.17 → 1.0.18	ok (protocolVersion 1)	auth required (-32000, "no auth method id provided")

All four 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; every package was a cold fetch this run, since the host restarted and cleared the npx cache. Entrypoints (--acp for codebuddy and dirac, acp for dimcode, agent stdio for grok) are unchanged.

dirac skips three patch releases at once (0.5.2 → 0.5.5) and dimcode still self-reports agentInfo.title as "DimAgent" against a public listing of "DimCode" — a standing vendor quirk, not an AionCore defect. dirac's session catalog (mode, model, thought_level) is evidence only and is not persisted; skill step 11 leaves those columns to the runtime.

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.143.0 → 2.143.1. All four outgoing versions were scanned across crates/**/*.rs with fixed-string matching before staging; codebuddy's is the only real assertion and the other three have no hits. 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.

Snapshot comparison caveat: the usual per-agent distribution diff against the previous snapshot could not run this time — the host restarted and cleared /tmp, taking the prior registry.json with it. Structural claims here are therefore limited to what this snapshot alone shows: the id set is unchanged at 39, and each of the four drifted entries still declares the same distribution type and the same entrypoint args our lock uses. Whether any non-lock agent changed distribution shape overnight is unverified for this run.

The other 7 Registry-pinned packages (autohand, deepagents, glm-acp-agent, kilo, nova, pi, sigit) match the snapshot exactly. 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.09.03-3006ae2 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.