test: salvage the orphaned labels/disc triage, and extract build_labels

Thirteen agents triaging src/labels and src/disc died on a saturated
machine, leaving 5,836 insertions across 28 files uncommitted in a
worktree. Recovered by 3-way apply onto twelve commits of drift; zero
conflicts. The diff was archived to freemkv-private first, because a
worktree is not a backup and this one had already nearly been lost.

One production change, and it is the right one: mpls_universal::parse
read every playlist off the disc AND converted the entries to labels in
a single function, so the conversion — stream-type mapping, dedup key,
the dense global counters — could only be reached through a synthetic
UDF image. Extracted to build_labels(&[Playlist]), which unit tests can
drive from already-parsed values. Behaviour-preserving: same iteration
order, same skip-on-error.

Two collisions resolved by hand:

A second mod pass_progress_tests, written independently against the
same survivors as the one committed in c610285. Kept mine — it covers
the distinct-counters case and the Progress blanket impl, which theirs
does not — but theirs had three clamp tests mine lacked: good_pct,
bad_pct and pending_pct also clamp an overshoot, and I had only tested
that for work_pct. Merged those in as one test and proved each of the
three clamps load-bearing by removing them individually.

An unused_parens warning in a new fixture.

Method note, recorded because it cost real time: git apply --3way
STAGES its result, so `git diff` reads empty and the tree looks
untouched. I nearly concluded the patch had silently failed. Worse, the
first attempt piped through `head -20`, so `echo exit=$?` reported
head's status rather than git's — the same mistake this audit has
already documented once. Check the real exit status, and check
--cached, not just the working tree.

src/progress.rs

@@ -472,6 +472,33 @@ mod pass_progress_tests {
         assert_eq!(p.pending_pct(), 75.0, "a sized disc must not report 0%");
     }
 
+    /// The three disc-relative percentages clamp an overshoot too, not just
+    /// `work_pct`. A counter can transiently exceed the disc size while a pass
+    /// re-reads a region, and a client fed 137% renders past the end of its bar.
+    #[test]
+    fn the_disc_percentages_clamp_an_overshoot_to_a_hundred() {
+        let over = |f: fn(&PassProgress) -> f64, set: fn(&mut PassProgress)| {
+            let mut p = PassProgress {
+                bytes_total_disc: 1000,
+                ..sample()
+            };
+            set(&mut p);
+            f(&p)
+        };
+        assert_eq!(
+            over(PassProgress::good_pct, |p| p.bytes_good_total = 5000),
+            100.0
+        );
+        assert_eq!(
+            over(PassProgress::bad_pct, |p| p.bytes_unreadable_total = 5000),
+            100.0
+        );
+        assert_eq!(
+            over(PassProgress::pending_pct, |p| p.bytes_pending_total = 5000),
+            100.0
+        );
+    }
+
     /// The three disc-relative percentages read three DIFFERENT byte counters.
     /// Nothing above would catch `bad_pct` reading `bytes_pending_total`: each
     /// test sets one counter and leaves the others zero, so a swapped field