Benchmark kits sharing a label prefix across builds: an inherited prefix silently mislabels new arms

In a benchmark harness that generated per-row labels from a shared prefix plus per-phase additions, phases added for a NEW executable/build inherited the old build-specific prefix. The prefix named the old exe as the single exe for all arms, said a feature was deliberately not selected, and quoted an old baseline. So the labels of an already-accepted result table described the wrong build. The numbers were fine; the provenance text was wrong. An auditor caught it only by reading generated labels against the kit diff. Fixes: (1) build-specific label text must come from the build or arm definition, never from a shared prefix; (2) add a stub assertion that each new phase label names its own build and does NOT contain known old-build phrases; (3) treat a misleading label on an accepted table as a correction on the record (dated note next to the table), not just a backlog item, because labels are part of the claim.