fix(ci): the build pushes one tag; the rest are written registry-side (#3190)

buildx on this runner pushes the first tag to the registry and then
re-pushes the remaining ones through the DOCKER driver, reading them out
of a local image store that a registry-direct build never populated:

  #27 pushing …/fabledcurator:latest           DONE 15.8s
  #28 pushing …/fabledcurator:c-0e15c44 with docker
  #28 ERROR: tag does not exist: …:c-0e15c44

It is intermittent — build-ml made the identical two-tag push seconds
later in the same run and succeeded — and the consequence is worse than
the red job suggests. `:latest` had already published, so production was
correct while the immutable rollback tag rule 145 requires of every main
push simply did not exist. Nothing else would ever have noticed: a
missing :c-<sha> has no consumer that fails, so it surfaces at the moment
somebody needs to roll back, which is the worst time to learn a rollback
target was never written.

So the build now pushes exactly one ref — the channel's — and the
existing repoint step, which already excluded the source tag and already
ran on every reuse, now runs on the build path too and owns every other
tag. `imagetools create` is a registry-side manifest copy: no local
daemon, nothing that can be absent. This adds no new code path; it puts
the build case onto the one that was already proven.

Chosen over the alternative of asserting each tag resolves after the
build, which would have made the failure loud without making it rarer.

The cost, accepted: `imagetools create` wraps its source in an index, so
:c-<sha> is an index rather than a plain image and fc.revision does not
resolve through it. Nothing reads that label off :c-<sha> — the reuse
check only ever inspects the CHANNEL tag — and the index names the same
manifest, so a pull is byte-identical. The reuse path already produced
:c-<sha> this way; this only makes it uniform.

`build_tags` goes with it — the tag list now has exactly one consumer.

ci-requirements.md

@@ -108,6 +108,18 @@ per `docs/process.md`'s "add deps to the image when used by >1 project".
   source tag — `imagetools create` wraps its source in a manifest index, and
   config labels do not resolve through an index, so writing the channel tag
   from itself destroys the label the next run reads (#3183).
+- **The build pushes exactly ONE tag — the channel's — and every other tag is
+  written registry-side afterwards** (#3190). buildx on this runner pushes the
+  first tag to the registry and then re-pushes the rest through the docker
+  driver, out of a local image store that a registry-direct build never fills;
+  it fails intermittently with `tag does not exist`. On `dev` that only reddens
+  a job, but on `main` it silently skips `:c-<sha>` while `:latest` publishes
+  fine — a missing rollback tag has no consumer that fails, so nothing but the
+  red job would notice until somebody needs to roll back. `imagetools create`
+  has no local store to be absent from, and it is the code the reuse path
+  already ran, so both paths now share one proven route. The cost: `:c-<sha>`
+  is an index rather than a plain image, so `fc.revision` does not resolve
+  through it — nothing reads it there, and the index names the same manifest.
 - **`FC_CHANNEL` and `FC_VERSION` are build args, not runtime settings.**
   `build.yml` passes them to the web image only — the ml and agent images have
   nothing to report them to. `/api/health` returns both, the foot of Settings