chore(tools): bump Docker toolchain to latest stable versions

[arcbox-labs]

Summary

• docker: 29.7.2 -> 29.8.0
• docker-buildx: 0.36.1 -> 0.37.0
• docker-compose: 5.4.0 -> 5.5.1
• docker-credential-osxkeychain: 0.9.8 -> 0.9.9
• kubectl: 1.36.3 -> 1.37.0

Checksums verified by downloading binaries and computing SHA-256.

Before merging a docker bump: check it against the guest dockerd in the boot bundle [boot] pins (upstream.toml at that tag in the boot-assets repo). See the header of assets.lock — the two are meant to diverge only between a bundle release and the [boot] bump. buildx and compose have no guest-side twin.

Auto-generated by cargo xtask release check-tool-updates.

[pullfrog]

✅ No new issues found.

Reviewed changes — a mechanical, xtask-generated bump of two host-side darwin tool pins in assets.lock:

• docker-compose 5.4.0 → 5.5.0, with updated arm64/x86_64 SHA-256 checksums.
• kubectl 1.36.3 → 1.36.4, with updated arm64/amd64 SHA-256 checksums.

I re-downloaded all four binaries from the exact URLs the consumer (app/arcbox-docker-tools/src/registry.rs) and the generator (xtask/src/commands/release/check_tool_updates.rs) use, and all four SHA-256s match the pins byte-for-byte. Both versions are the current upstream latest (docker/compose latest release = v5.5.0; kubectl stable.txt = v1.36.4), and since both tools are ArtifactFormat::Binary, the checksums correctly cover the raw binaries.

The boot-bundle coordination warning in the PR body doesn't apply here — it guards docker-group tools that twin the guest dockerd, but only docker-compose (no guest twin) and kubectl (host-only kubernetes group) changed; the docker pin (29.7.2) and [boot] (0.8.6) are untouched.

  ^{｜ View workflow run ｜ Using openai-compatible/@cf/deepseek-ai/deepseek-v4-flash-0731 ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — re-review of the new commit (84adc86), a re-run of the tool-update generator on top of the previously reviewed state:

• Added docker-credential-osxkeychain 0.9.8 → 0.9.9 with fresh arm64/amd64 SHA-256 pins.
• Retargeted kubectl from 1.36.4 to 1.37.0 — upstream stable has since moved, so the previously reviewed 1.36.4 pins were replaced with 1.37.0 ones.
• docker-compose 5.5.0 unchanged from the previously reviewed commit.

I re-downloaded all four binaries from the exact URLs app/arcbox-docker-tools/src/registry.rs builds and all four new SHA-256s match the pins byte-for-byte. Both versions are the current upstream latest (https://dl.k8s.io/release/stable.txt = v1.37.0; docker/docker-credential-helpers latest release = v0.9.9), and both tools are ArtifactFormat::Binary, so the checksums correctly cover the raw binaries. The boot-bundle caution in the PR body still doesn't apply — the docker pin (29.7.2) and [boot] (0.8.6) are untouched, and none of the three bumped tools has a guest-side twin.

  ^{｜ View workflow run ｜ Using openai-compatible/@cf/zai-org/glm-5.3-flash ｜ 𝕏}

[pullfrog]

Important

The new docker bump breaks the boot-bundle coordination contract: the pinned (and newest published) boot bundle 0.8.6 ships guest dockerd 29.7.2, so merging as-is leaves the host CLI a release ahead of the guest daemon with no bundle release in between. Details inline on assets.lock:26.

Reviewed changes — re-review of the new commit (fb5feec), a fresh cron re-run of cargo xtask release check-tool-updates on top of the previously reviewed state:

• Bumped docker 29.7.2 → 29.8.0 — the first docker-group bump in this PR, which activates the boot-bundle caution in the PR body for the first time.
• Bumped docker-buildx 0.36.1 → 0.37.0 with fresh arm64/amd64 pins.
• Re-bumped docker-compose 5.5.0 → 5.5.1, superseding the previously reviewed 5.5.0 pins.
• kubectl 1.37.0 and docker-credential-osxkeychain 0.9.9 are untouched by the new commit and carry over from the previously verified delta.

All six changed artifacts re-downloaded from the exact URLs app/arcbox-docker-tools/src/registry.rs builds: every new SHA-256 matches its pin byte-for-byte (docker pins hash the .tgz archive per ArtifactFormat::Tgz, the rest the raw binaries), and all three bumped versions are the current upstream latest via the generator's own endpoints (moby/moby latest release = docker-v29.8.0; download.docker.com lists docker-29.8.0.tgz; buildx = v0.37.0; compose = v5.5.1). The checksum work is clean — the one must-address finding is inline.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using openai-compatible/@cf/zai-org/glm-5.3-flash ｜ 𝕏}

[pullfrog]

This bump now trips the PR body's own merge gate: boot bundle 0.8.6 — both the [boot] pin and the newest bundle published to the CDN — ships guest dockerd 29.7.2, so merging puts the host CLI a release ahead of the guest daemon with no bundle release in between. That standing skew is exactly what assets.lock's header confines to the window between a bundle release and the [boot] bump; the skew is runtime-tolerable (the CLI negotiates down) but the contract says keep the pins in step.

Either hold this pin at 29.7.2 and merge the buildx/compose bumps now, or cut the boot-assets bundle carrying dockerd 29.8.0 and bump [boot] version + manifest_sha256 in this same PR.

Technical details

# Host `docker` CLI bump desyncs from the guest dockerd pin

## Affected sites
- `assets.lock:26` — `[[tools]] docker` bumped 29.7.2 → 29.8.0 while `[boot]` stays 0.8.6. The header (`assets.lock:11-16`) and `app/arcbox-docker-tools/src/lockfile.rs:8-15` require the two pins to stay in step, diverging only between a bundle release and the `[boot]` bump.
- Evidence — guest dockerd is 29.7.2 in three primary sources: `upstream.toml` at tag `v0.8.6` in `arcboxlabs/boot-assets`; the live CDN manifest `https://boot.arcboxcdn.com/asset/v0.8.6/manifest.json` (`"version": "29.7.2"` for dockerd, containerd-shim-runc-v2, runc, docker-init); `docs/boot-assets.md:13`. CDN `latest.json` reports 0.8.6 as the newest bundle, so no 29.8.0-carrying bundle exists yet.

## Required outcome
- `[[tools]] docker` and the boot bundle's dockerd version are equal at merge time (or the divergence confined to a documented bundle-release → `[boot]`-bump window — not the case here, since no new bundle exists).

## Suggested approach
- Option A: revert this pin to 29.7.2 and merge the buildx/compose bumps. Caveat: the Monday cron will re-propose the docker bump until a bundle exists, so this only buys time.
- Option B: release a boot-assets bundle carrying dockerd 29.8.0 first (bump `DEFAULT_CONTAINERD_REF` there too, per that repo's header), then bump `[boot] version` + `manifest_sha256` in this PR alongside the `[[tools]]` change.
- Note the generator (`xtask/src/commands/release/check_tool_updates.rs`) cannot see the boot-assets repo, so either way the coordination is manual — the PR body's caution is the only gate.