Deploying without the CLI

We are evaluating celld for a multi-tenant SaaS. Our customers require their data to sit in their own blob storage container, and some run on their own release cadence, so the shape is one fleet per customer with its own bucket and its own pinned version. That is a few hundred fleets. Our control plane would publish a Worker bundle to one bucket when a tenant is provisioned, and to many buckets, not necessarily all, on each release.

We would rather not shell out to `celld deploy` from a service. From `crates/celld/deploy.rs`, the CLI writes an immutable prefix (`modules`, `manifest.json`, `assets.json`) and then moves `deploy//current.json` and `deploy/current.json`. `Manifest` already carries `schema_version` and `required_features`, and `DeployPointer` has `rollout.percent`.

Two questions:

1. Can we write that layout ourselves (esbuild library + storage SDK) and rely on it, with a node refusing an unknown `schema_version` and keeping its current deployment? Or is the CLI the only supported path and the layout may change without notice?
2. If writing the bucket directly is not the intended route, would a deploy endpoint on the internal listener be in scope, taking a prebuilt bundle and doing what the CLI does?

Start by reading crates/celld/deploy.rs, especially Manifest, DeployPointer, and the pointer-writing flow. Determine whether the bucket layout and schema handling are supported contracts or internal details, then review the internal listener entry points for an existing deployment API. Done means documenting the supported integration path or agreeing on a scoped endpoint proposal.

Written by the indexing model from the issue text.