Make sync-artifacts unable to half-publish a benchmark run

[EHxuban11]

Follow-up to #7. That PR guarded wrong numbers; this one guards incomplete artifacts.

Three times in the 2026-08 campaigns the uploader printed uploaded N, skipped 0 while shipping something unreproducible. A crash is loud and stops you. This produced a green log, a real HF URL, and a submission with correct numbers — everything you'd check as a sanity test passed. The only way I caught it was enumerating the repo afterwards.

All of it traced to one line in collect_artifacts:

def add(path, repo_path):
    if path.is_file():
        items.append(...)      # else: silence

"not present" and "not applicable" were the same thing.

What

1. Pass the resolved recipe_path. cmd_sync_artifacts computed a fallback for the manifest, then handed collect_artifacts args.recipe instead. A sync without --recipe wrote a manifest naming a recipe and uploaded none. This is the actual root cause of three published runs citing a recipe_sha256 whose file exists nowhere.
2. Collect the flat <root>/<dataset>/<weight file> layout too. That is what --weights-root documents and what the evaluator reads. Only .runs was collected, so any other weights root uploaded zero checkpoints silently. The uploader and evaluator disagreed about where checkpoints live.
3. Refuse to publish an incomplete checkpoints/all tier. Every dataset with a stats.json must ship a checkpoint; recipe and versions lock must be present. results only reports, so ordinary syncs stay non-brittle.
4. Verify the recipe against the hash the submission claims. The fallback resolves the packaged family recipe, wrong for any run with a custom --recipe.

Why 4 matters most

Fixing 1 alone would make things worse. The fallback would start uploading recipes/rf100vl/yolox.json as provenance for runs that actually used a custom recipe — labelling a run with a recipe that did not produce it. Shipping the wrong recipe is worse than shipping none: it converts a visible gap into an invisible contradiction. 1 and 4 have to land together.

There's a matching asymmetry this closes: the harness already refuses to call a submission valid when the recipe hash is missing (that is how it caught a corrected run this morning), but happily published when the recipe file was missing. It validated the pointer and never checked the referent.

Check

tests/test_publish_completeness.py (new, 7 tests) written against the three real failures: flat-layout checkpoints are collected, .runs still works, a trained dataset without a checkpoint raises, a missing recipe raises, results tier only reports, a mismatched recipe raises, a matching one is accepted.

Full harness suite: 153 passed.

One existing test (test_collect_tiers_add_weights_progressively) needed a recipe fixture — it exercises tier layering with tier="checkpoints", which the contract now requires a recipe for. Behaviour under test is unchanged.

Not verified

• The completeness contract keys off stats.json as "this dataset trained". A campaign that writes checkpoints without stats would not be checked.
• IncompletePublish is a hard failure for programmatic callers of collect_artifacts at publishable tiers, not just the CLI. That is deliberate, but it is an API behaviour change.
• Not fixed here: the campaign auto-sync path has its own collect_now() closure that passes neither eval_dir nor submissions_dir, which is why auto-sync runs carry no predictions or submissions. That looks intentional (the standalone sync is the publishing step) but it is worth confirming.