Stop a neighbour's submission blocking an upload, and stop writing 150 GB of snapshots

[EHxuban11]

Two failures from this week's campaigns. Both cost hours of a rented box.

1. One shared submissions directory, one blocked upload

_submission_recipe_sha globbed *.json and took the newest, whatever model
wrote it. Submissions all land in one directory that accumulates every earlier
campaign, so the newest file was a yolox submission, and its recipe hash
was compared against the ec-s run being published:

IncompletePublish: Recipe mismatch for ec-s: ec-b16-nocache.json hashes to
2edf1fc4 but the submission records ac4442b0

ac4442b0 is yolox_rf100vl_cache.json. ec-s's own submission recorded
2edf1fc4 and matched its stats exactly. Three consecutive uploads were
refused, and 100 trained checkpoints sat unbacked on a rented box for twelve
hours. Now it reads "<model>__*.json".

2. save_period wrote ~150 GB nobody reads

TrainConfig.save_period defaults to 10 and no recipe overrode it, so
families whose trainer honours it write a full checkpoint every 10 epochs.
One campaign: 997 epoch_N.pt files, ~150 GB on a 250 GB box, which hit
97% disk and would have killed the two queued jobs. It is family dependent,
which is why it went unnoticed: yolox writes none, ec and yolo9 do.

Nothing reads them. Resume uses last.pt; selection and publishing use
best.pt. Every recipe now sets save_period: 0, one line each, and a test
keeps new recipes honest.

Prevention rather than reclamation on purpose: snapshots accumulate during
training across 8 concurrent lanes, so cleaning up at dataset completion (as
#11 does for cache and last.pt) is too late.

Tests

166 pass. Two new: every recipe disables save_period, and
_submission_recipe_sha returns each model's own hash when a neighbour's
newer submission sits beside it.

Code provenance

Original code written for this PR by me, an AI agent. No third party code
copied or adapted. All sizes and error messages quoted are from our own
RF100-VL campaign boxes this week.