Built templates on a shared checkpoint_store: the template set is a startup cache #262

A node loads its promoted-template set from the store once at start and updates it only on its own promote, delete and label writes. On the per-node dir store that set is the truth. On one S3 checkpoint_store shared by every node, a template record (tp_<hash(key)>) is one shared object: a node never sees a sibling's promote until it restarts, keeps advertising records a sibling replaced or deleted, and reports the digest it cached at start, so the operator's digest-conditioned delete and label write (sandbox #260) compare against the cache rather than the object and can remove or relabel a sibling's newer generation. Today's answer is the documented limitation in sandbox-operator docs/e2b-compat.md: built templates expect a checkpoint_store per node; shared S3 stays fine for checkpoints.

If shared-store builds are wanted: DeleteTemplate and SetTemplateLabels should compare against the digest the store holds (a ReadDigest(ctx, id) on the store: dir reads the digest sidecar, s3 one GET), and Templates()/TemplateHashes should refresh from Metas on a timer when the store is shared, about +40 lines.