Function apply_updates 

pub fn apply_updates(
    store: &LocalFsStore,
    flags: &OpFlags,
    payload: Option<ApplyUpdatesPayload>,
) -> Result<OpOutcome, OpError>

op updates apply — apply a STAGED update plan to its environment (Phase 3 of the Greentic updater). Mutation.

The staged plan (from op updates get) is re-verified end-to-end off the on-disk staging tree before any environment mutation — DSSE signature, per-artifact checksums, the tamper cross-check against the write-time digest, the target-env identity, and the downgrade + compat gates against the current applied set. Re-verification is defense-in-depth: the plan was verified at get, but the bytes sitting on disk are untrusted at apply time.

A passing plan is then applied under a whole-env snapshot: staged → applying, snapshot the environment (P0b), drive the declarative env_apply pipeline with the plan’s signed target manifest, and on success applying → applied (so latest_applied_sequence advances). On ANY apply failure the pre-apply snapshot is restored and the plan is marked failed. A plan stranded in applying from a prior crash is failed closed (re-stage via op updates get). The mutating region runs inside audit_and_record.

Scope of this increment: content add/update only (the manifest is upsert-applied — resource removal/prune is deferred). Success means the env store converged (env_apply’s internal verify); live runtime health is not gated here (the deployer cannot reach greentic-start’s health gate). The binary self-update track is not built; a plan carrying binaries would fail the manifest parse. Fail-closed guards on the target manifest (see [check_applyable_manifest]): bundles must be bundle_digest-pinned (so env_apply verifies the applied bytes against the signed plan), and secrets[] / messaging_endpoints[] (which write dev-store secret material) are applyable only when the effective Secrets sink is the P0b-snapshotted dev-store, so a failed apply can roll those writes back. Concurrent apply on one env is single-flight: begin_apply_checked admits at most one plan into applying per env under the staging lock, rejecting a second, and runs the downgrade/compat re-gate atomically with the staged → applying transition.