feat: let a preloaded deployment skip its universe load, and deploy_env load the universe

[mandykwok-scale]

Why

deploy_env with an artifact_id doesn’t load that universe: a cold build comes back empty, so a task needs a separate load_artifact. With a warm pool, that means a hit loads the same ~6 minutes of data again, and a miss depends on load_artifact being there. This PR lets a provider promise a loaded env (delivers_universe): deploy_env then hands back an env holding the universe whether the pool had one ready or the env was built cold.

What

• EnvironmentProvider.delivers_universe (off by default). For a provider that sets it, such as the warm pool's pooled provider, deploy_env loads its universe after deploying and records the load as load_artifact does. Its task needs no load_artifact.
• DeployedEnv.preloaded_universe: a provider sets it on an env it hands over already holding a universe. The load above is skipped when that names the universe and version asked for and the env's data hasn't changed since (empty changelog, VM mode only).
• Loading a different universe, or reloading a single service, clears preloaded_universe, so it can't cause a wrong skip later.

No built-in provider sets the flag, so existing flows are unchanged.

Testing

Unit tests cover the deploy-time load for a provider that sets the flag (and none for one that doesn't, or with no universe), the skip and each case that must load instead, and clearing preloaded_universe. Only those test files were run, not the full suite.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no new actionable defect was found.

Summary

Providers can opt into loading a universe during deploy_env. A matching, untouched preloaded universe skips the data load while still recording the result and staging metadata.

• Deploy steps load requested universes and skip data already in place.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Deploy environment] --> B{Provider promises a loaded universe?}
  B -->|No| C[Return deployment]
  B -->|Yes| D{Requested universe already loaded and untouched?}
  D -->|Yes| E[Skip data load]
  D -->|No| F[Clear preloaded guarantee]
  F --> G[Restore snapshot or load services]
  E --> H[Record universe and stage metadata]
  G --> H
  H --> C

Loading

_{Reviews (9) · Last reviewed commit: "refactor(load_artifact): drop the unused..." · Reviewed by Greptile}

[kaihackney-scale]

Looks good overall. The opt-in flag keeps existing flows unchanged, and Greptile's open P1 ("Wrong universe stays loaded") is addressed by b8ab33d2 (_void_preloaded_universe, persisted to the record), with test_loading_another_universe_voids_the_guarantee and test_the_void_reaches_the_stored_record covering it, so that thread can be resolved. One remaining gap, the single-service load path, is inline.

Two cross-PR notes:

• The title says "…and deploy_env load the universe", but no deploy_env change is in the diff. The title becomes the squash subject, so worth fixing.
• Nothing sets skip_if_preloaded=True yet: scaleapi#166525's deploy_compose doesn't pass it, so after both merge a pool hit still reloads. Flagged on that PR too.

[mandykwok-scale]

Thanks! The design changed: a provider that sets delivers_universe (only pooled) gets its universe loaded in deploy_env itself, skipped when it arrived with it untouched. So the title is now accurate, and #166525 composes pooled deploys with no load_artifact at all, so nothing needs to pass skip_if_preloaded.

[mandykwok-scale]

Closing: replaced by loading the universe in the pooled provider itself (scaleapi/scaleapi#166525, d1f3511e359). On a miss the provider builds cold, then loads the universe through an env opened on the record with MultiEnv.from_deployed_env, so deploy_env needs no change and no framework flag is needed.