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

[arcbox-labs]

Summary

• docker: 29.6.2 -> 29.7.1
• docker-buildx: 0.35.0 -> 0.36.0

Checksums verified by downloading binaries and computing SHA-256.

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

[pullfrog]

ℹ️ Pins verified correct — one version-skew question worth a look.

Reviewed changes — an automated check-tool-updates bump of two [[tools]] pins in assets.lock; I re-verified every checksum against upstream rather than taking the generated body's word for it.

• docker 29.6.2 → 29.7.1 — host Docker CLI, installed from the download.docker.com static tarball.
• docker-buildx 0.35.0 → 0.36.0 — buildx CLI plugin, installed as a bare binary from GitHub releases.
• Nothing else moved — [boot] (0.6.13), manifest_sha256, docker-compose, docker-credential-osxkeychain, pstramp, and kubectl are untouched.

Independent verification, so it does not have to be repeated:

• All four sha256 values match the real artifacts byte-for-byte (streamed and hashed), and all four URLs return 200.
• The URL templates in xtask/src/commands/release/check_tool_updates.rs match the runtime ones in app/arcbox-docker-tools/src/registry.rs, so the hashed artifact is the one HostToolManager will download. The docker sha correctly pins the archive, which is what is_cached / validate_all expect for ArtifactFormat::Tgz.
• The 29.7.1 tarball still contains exactly docker/ + docker/docker, so the hardcoded registry::tgz_inner_path("docker") still resolves and extract_from_tgz will not start failing.
• assets.lock is the only pin site in this repo — package_tarball.rs stages no docker/buildx binary or .sha256, and a stale .app-bundle sidecar degrades gracefully to a CDN download.
• ArcBox's own docker invocations (rootfs_builder.rs, uninstall.rs) use --context, image inspect, build -t -f, and context rm/use — all unchanged in 29.7.x, which ships only additive features and bug fixes with no flag removals or Engine API minimum bump.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

This takes the host CLI to 29.7.1 while boot bundle 0.6.13 still ships dockerd 29.6.1, widening the gap from patch-level to minor-level. The header at lines 11-14 tolerates that divergence only "for the short window between a bundle release and the [boot] bump", but the weekly cron has no awareness of the [boot] half, so nothing closes the window automatically. Almost certainly fine in practice via API negotiation — worth confirming someone owns the follow-up bump.

Technical details

# Host Docker CLI pin now a minor version ahead of the guest dockerd

## Evidence
- Fetched `https://boot.arcboxcdn.com/asset/v0.6.13/manifest.json` (its sha256
  matches the `manifest_sha256` pin on line 19 exactly, so this is the bundle
  this repo actually boots). It pins `dockerd` and `docker-init` at `29.6.1`.
- Before this PR: CLI 29.6.2 vs dockerd 29.6.1 — same minor.
- After this PR: CLI 29.7.1 vs dockerd 29.6.1 — one minor ahead.

## Affected sites
- `assets.lock:24` — the CLI pin this PR moves.
- `assets.lock:11-14` — the rule this crosses: keep the `docker` tool on the
  same version as the boot bundle's dockerd, diverging only briefly.
- `app/arcbox-docker-tools/src/lockfile.rs:5-6` — doc comment asserts "A single
  lockfile ensures the Docker CLI and guest dockerd are always at the same
  version — no version-skew concerns on upgrade." That is not true and this PR
  makes it visibly wrong: dockerd comes from the boot manifest, not
  `[[tools]]`, exactly as `assets.lock`'s own header states.
- `docs/boot-assets.md:13,31` — states the bundle is built from the "Docker
  29.6.1 static package". Accurate for `0.6.13`, so it will need updating in
  the same change that moves `[boot]` to a 29.7.x bundle.

## Required outcome
- A decision on whether merging ahead of the bundle is acceptable here, and if
  so something tracking the follow-up `[boot]` + `manifest_sha256` bump once
  `boot-assets` publishes a 29.7.x-based release.
- Correct or delete the `lockfile.rs:5-6` version-skew claim so it stops
  contradicting `assets.lock`'s header.

## Open questions for the human
- Is the intended sequence "bump `[boot]` first, then let the cron move the
  CLI"? If so, this PR arrived out of order and may be worth holding.
- Should `check-tool-updates` warn when the `docker` tool pin's minor version
  diverges from the pinned bundle's dockerd, so this is caught at generation
  time rather than in review?