audio: cover ordinary serial lengths in parse tests

Codex round 1 (P3): the valid cases were only 1, 10 and 20 digits long,
so `if (2..10).contains(&raw.len()) { return None }` survived all four
tests while rejecting every serial a freshly started daemon hands out.
Verified: that mutant passes the old suite and fails the new test.

Also corrects the doc comment — leading zeroes are accepted (harmless
and unambiguous), only whitespace padding is rejected.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

src/host/audio.rs

@@ -612,8 +612,9 @@ fn run_router(
 /// sink is never registered and no stream is ever routed.
 ///
 /// Strict on purpose: PipeWire emits a bare decimal, so anything else
-/// (empty, signed, padded, non-numeric) is a property we do not
+/// (empty, signed, whitespace-padded, non-numeric, overflowing) is a
-/// understand and must not guess at.
+/// property we do not understand and must not guess at. Leading zeroes
+/// are accepted — they are unambiguous and parse to the same value.
 fn parse_object_serial(raw: &str) -> Option<u64> {
     if raw.is_empty() || !raw.bytes().all(|b| b.is_ascii_digit()) {
         return None;
@@ -704,6 +705,23 @@ mod tests {
         );
     }
 
+    #[test]
+    fn object_serial_accepts_ordinary_serials() {
+        // Without this the valid cases are only 1, 10 and 20 digits long, and
+        // a length-gated mutant (`if (2..10).contains(&raw.len()) { None }`)
+        // survives the whole suite while rejecting every serial a freshly
+        // started daemon actually hands out. (Codex, round 1.)
+        for serial in 0_u64..=1024 {
+            assert_eq!(parse_object_serial(&serial.to_string()), Some(serial));
+        }
+        assert_eq!(parse_object_serial("123456789"), Some(123_456_789));
+        assert_eq!(
+            parse_object_serial("007"),
+            Some(7),
+            "leading zeroes are fine"
+        );
+    }
+
     #[test]
     fn object_serial_boundary_values() {
         assert_eq!(parse_object_serial("0"), Some(0));