fix: the ml artifact was in a second list I never grepped for (4311)

ac70f2a removed the `ml` image but CI went red on six tests:
`tests/test_artifact_identity.py` parametrises over its own
`ARTIFACTS = ("web", "ml", "agent", "extension")`, and every case now hits
the dispatch guard that same commit added.

My miss, and a specific one. I grepped for `fabledcurator-ml` and `ML_PATHS`
and called the survey done — but the artifact is also named as a bare `"ml"`,
which neither pattern finds. Rule 90 (grep pinned tests when changing a
shared symbol) was surfaced to me while I was making the change and I ran a
narrower sweep than it asks for. Lesson #4275 names the shape exactly: an
absence claim is only as good as the search behind it, and a grep that
matched nothing looks identical to a grep that asked the wrong question.

The re-run was done by value, not by name: every occurrence of a bare `ml` in
the repo, then filtering. That distinguishes the two things the token means —
the celery LANE `ml` and the `backend/app/services/ml` package both stay and
account for nearly every hit; only the IMAGE name went. Worth stating in the
test, since the next person to grep will hit the same ambiguity.

Also swept the prose the first pass left describing the old pipeline: "Four
artifacts" (README, ci-requirements), "leaves web and ml alone" (×5 in
build.yml, plus both docs), "CI publishes it alongside the web/ml images"
(agent/README). The run 4896 build-time measurements keep their `ml` number —
that was measured when ml was a real build — with a note saying the name has
since gone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR

ci-requirements.md

@@ -99,8 +99,8 @@ per `docs/process.md`'s "add deps to the image when used by >1 project".
 - **`scripts/artifacts.sh` is the same shape one level up: one definition per
   artifact of what it is built from, and the two values derived from it.**
   `revision` (12 hex of the newest commit touching that set) and `version`
-  (`YYYY.MM.DD.HHMM` UTC, rule 148). Four artifacts, four independent answers,
-  so a push touching only `agent/` leaves web and ml alone.
+  (`YYYY.MM.DD.HHMM` UTC, rule 148). Three artifacts, three independent
+  answers, so a push touching only `agent/` leaves web and the extension alone.
   `tests/test_artifact_paths.py` reads each Dockerfile and asserts every COPY
   source is covered, so adding a COPY without updating the script fails CI.
 - **A file that DECIDES an artifact's identity belongs in its set even though it
@@ -153,7 +153,8 @@ per `docs/process.md`'s "add deps to the image when used by >1 project".
   layer store at all**, where the old `docker` driver at least reused whatever
   the runner's dockerd happened to hold. Measured on run 4896, the first builds
   after the driver moved: web 3m44s (was 2m23s), ml 3m49s (was 3m20s), agent
-  11m12s (was 9m26s) — every one slower. A `:buildcache` tag is read by every
+  11m12s (was 9m26s) — every one slower. (`ml` was its own build then; #4311
+  retired it once it became the same bytes as web under a second name.) A `:buildcache` tag is read by every
   build that runs, is one moving ref per image, holds cache blobs rather than a
   shippable artifact, and is overwritten in place, so it is not a return of the
   per-version tags milestone 318 withdrew (#3114).