JuiceFS runtime maintenance

The checkpoint client is a pinned upstream JuiceFS commit plus one Platinum patch. It is not a floating release download.

This fork creates an ongoing maintenance obligation: upstream security fixes do not reach this binary automatically. The author of each runtime-update PR owns the upstream advisory review, patch rebase, and ABI/acceptance evidence; the release reviewer must verify that evidence before approving the update. If an upstream fix cannot be rebased safely, keep promotion blocked rather than silently retaining an affected client or dropping the checkpoint contract.

When updating it, change infra/juicefs-runtime/runtime.lock and the patch together. The lock must retain an immutable upstream commit, patch SHA-256, digest-pinned Go image, and RUNTIME_ABI. Run infra/build-juicefs-runtime.sh: it verifies source identity, applies the patch with git apply --check, builds offline after dependency resolution, and checks platinum-control --capabilities reports that exact ABI.

Run the runtime installer/build guard tests before review. A runtime-only push to main dispatches the canonical Development control-plane workflow before the host roll may proceed; Staging and Production are unchanged and receive it only through their normal promotion flow. Roll hosts serially after the control-plane manifest gate is satisfied, then run the relevant Development acceptance matrix. Do not replace the lock with a tag, an unpinned builder, or an ABI-compatible-looking binary without those checks.

Dispatch targets the current main branch. A later push can supersede an older host rollout; the unchanged exact-SHA manifest check must reject that stale rollout before host mutation. Dispatch success alone is not deployment proof.