fix(cloudflare): reuse unchanged container image digests

[danieljvdm]

Cloudflare container applications now resolve pushed tags to immutable registry digests and persist both the digest and a fingerprint of the complete desired application configuration.

A changed source hash can still produce the same registry manifest. When that happens, the provider preserves the live image reference and returns before updateContainerApplication when the desired scaling, placement, and runtime configuration fingerprint is also unchanged. A changed image digest or application configuration still follows the normal update and rollout path.

This is the default reconciliation behavior rather than an opt-in: an apply with no effective desired-state change should not create a new application version. Persisting the desired-state fingerprint avoids comparing against Cloudflare-enriched response defaults and ensures that removing a previously configured field is still recognized as a real change. Existing state without the fingerprint migrates conservatively through one normal update.

The digest has a single source: after a push (or for a pre-pushed tag) the provider asks the registry — HEAD /v2/<repo>/manifests/<tag> with the minted pull credentials — rather than scraping docker push output. A reference that already carries @sha256:… is used as-is.

Regression tests

All in ContainerApplication.test.ts, against the real registry and API:

• identical image re-push — the same remote image under two references changes the source hash but not the manifest; the live image and version must not change, and a genuinely different tag must roll out:

  const first = yield* deployImage(scratch, "mendhak/http-https-echo:41");
  const second = yield* deployImage(scratch, "docker.io/mendhak/http-https-echo:41");
  expect(second.app.configuration.image).toBe(first.app.configuration.image);
  expect(yield* live(accountId, first.app.applicationId)).toMatchObject({
    version: first.app.version,
    image: first.app.configuration.image,
  });

  Without the fix the second deploy swaps the live image to the freshly pushed :<sourceHash> tag and creates a rollout.

• pre-pushed tag reference — a consumer referencing the pushed <repo>:<sourceHash> tag resolves to the same digest reference as one referencing <repo>@sha256:… (exercises the registry probe directly).

• legacy state migration — the row is rewritten to a pre-digest shape (hash.image only, live image rolled back onto the tag); the next drift deploy keeps the tag reference, persists the digest + fingerprint through one update, and every later drift is a noop.

• Durable Object re-create — the live app is replaced out-of-band by a same-name app without the DO attachment (what precreate leaves behind) with a staled source hash; the re-create path rebuilds, matches the digest, and attaches the DO without changing the image reference.

[sam-goodwin]

Are there any regression tests we can add to exercise this?