Close the Ok-but-empty clip hole on HD-DVD; keep it open, and say why, on BD

The same hole, two disc families, two answers — and the asymmetry is now a
decision written into both files instead of an oversight in one.

`file_extents` can return `Ok` and still yield no usable extent: an empty
allocation-descriptor list, or one every entry of which the `sectors > 0 &&
lba > 0` filter discards. An ordinary zero-byte file reaches it; no crafted
disc is needed.

On HD-DVD that was the flagship failure shape. The clip entered neither
`clip_extents` nor `unusable`, and nothing was logged, so the composer's
`any(|n| unusable.contains(..))` guard missed it while the
`filter(|n| clip_extents.contains_key(..))` beside it quietly deleted the
part: a `FEATURE_2.EVO` of size 0 next to a healthy `FEATURE_1.EVO` composed
a FEATURE title out of part one alone, still advertising the whole runtime,
at rc=0, in silence. Half a movie presented as a whole one. Round 1 accounted
for every `Err` from the resolver and left this route open. It now marks the
clip unusable and logs it under its own new code, E6019
(`E_UDF_NO_USABLE_EXTENT`) — deliberately not the neighbouring E6017, which
would file a zero-length file as an authoring hole and send whoever triages
it at the wrong population.

On Blu-ray the identical hole stays open, as previously decided, and the
reasons are now recorded on both sides. BD has no `unusable` set, so closing
it there means inventing a post-loop "every clip_id must appear in `spans`"
invariant that DROPS the title, and it is not settled that an empty-but-Ok
resolve is always a defect; dropping healthy titles is worse than the gap.
The consequence is milder too: on BD the clip is one PlayItem of an otherwise
whole title, on HD-DVD the feature is COMPOSED from parts. Same hole,
different price.

Also in this change:

* bluray: a non-absence SSIF failure that the `.m2ts` fallback papers over is
  logged. `unresolved` had exactly one reader, `if let (None, Some(code))`, so
  when `/BDMV/STREAM/SSIF/<clip>.ssif` failed with DiscRead /
  UdfAdChainTooLong / UdfEmbeddedData and the base view then resolved, the
  code was recorded and thrown away: the title shipped base-view 2D off a 3D
  disc at rc=0 with no log at all. The site's own doctrine is "ABSENCE is the
  only benign failure". Logged, not refused — the base view is a real rip.

* drive: `wait_ready` polled TEST UNIT READY through a bare `execute` and its
  60 x 500 ms loop never read `self.halt`, so a Stop during spin-up did
  nothing for ~30 s while every other drive path returns Halted at the next
  command boundary. `spin_cycle` issued both START STOP UNIT commands outside
  `checked_exec` and slept `SPIN_DOWN_IDLE_SECS` + `SPIN_UP_SETTLE_SECS`
  blind — ~15 s deaf to Stop, from the recovery path, exactly when the
  operator is most likely to press it. Both now use `checked_exec` and
  `sleep_until_halted`, which already lived in this file with four tests and
  was `#[cfg(test)]`, called from nowhere. It is production code again.

* drive: a READ(10) that returns GOOD status with a residual underrun was
  correctly refused and logged NOWHERE, while the sibling `Err` arm warns with
  lba/count/status. A residual-underrunning drive was indistinguishable from a
  scratched disc — two populations with opposite remedies. It now warns with
  transferred vs expected, which is the whole signal.

* error: `all_error_code_constants_are_unique` was a hand-maintained `vec![]`
  naming 109 of the 127 declared codes while its doc claimed to pin them all,
  and an earlier audit trusted that claim while assigning new ones. The list
  is now derived from the declarations by parsing `include_str!("error.rs")`,
  so a new constant is covered the moment it is written. A parser self-test
  cross-checks the count and three known name/value pairs, so it cannot pass
  vacuously.

* testlog: a test-only `tracing` capture (~120 lines, no new dependency) so
  the logging contract is enforced rather than commented. Three sites carry
  long comments insisting they log the error's OWN code; putting a literal
  back broke nothing. They are pinned now, along with the two new log lines.
  Captures are serialised process-wide: `tracing`'s interest cache is global
  while `with_default` is thread-local, and the rebuild on the exiting
  capture can land after the entering one's, leaving the cache at "never"
  while a capture is live. That produced a real empty-event flake.

* disc: `scan_with`'s halt wiring for the BD and DVD enumerators had no test —
  every BD/DVD cancellation test calls the scanners directly, so passing
  `None` on either branch left the suite green while Stop did nothing.

* mux::network: `accept_from_rejects_stream_without_fmkv_header` half-closes
  instead of `Shutdown::Both`, which raced an RST against the server's read
  and returned ConnectionReset instead of InvalidInput under load. The port
  was already ephemeral; that was never the cause.

Gate: fmt, clippy --all-targets -D warnings, and 3439 tests green on 1.97;
precommit.sh libfreemkv clean.

src/mux/network.rs

@@ -627,16 +627,36 @@ mod tests {
     /// accept_from() must reject a connection whose first bytes are NOT the
     /// FMKV magic — there is no metadata to drive muxing, so it surfaces
     /// NoMetadata rather than proceeding with an empty/garbage title.
+    ///
+    /// FLAKE FIXED, not the behaviour under test: this used to
+    /// `shutdown(Shutdown::Both)` the instant the bytes were written. Closing
+    /// the READ half while the server had not yet read makes the kernel answer
+    /// the server's in-flight data with an RST, so `accept_from` came back
+    /// `ConnectionReset` instead of the `InvalidInput` this asserts — rarely
+    /// when run alone, reproducibly under the loaded concurrent suite, where
+    /// the server thread is descheduled long enough for the race to open. A
+    /// logging/protocol assertion that fails at random teaches the next person
+    /// to re-run until green, which is how a real regression gets waved
+    /// through.
+    ///
+    /// Half-closing (`Shutdown::Write`) delivers the same EOF the test needs
+    /// while leaving the read half open, and blocking on a read until the
+    /// server drops its end keeps the socket alive for as long as the server
+    /// is looking at it. The port was already ephemeral (`:0`), so it was
+    /// never a port collision.
     #[test]
     fn accept_from_rejects_stream_without_fmkv_header() {
+        use std::io::Read as _;
         use std::io::Write as _;
         let listener = TcpListener::bind("127.0.0.1:0").unwrap();
         let addr = listener.local_addr().unwrap();
         let handle = std::thread::spawn(move || {
-            // Raw non-FMKV bytes (not starting with 'F') then close.
+            // Raw non-FMKV bytes (not starting with 'F') then EOF.
             let mut s = TcpStream::connect(addr).unwrap();
             s.write_all(&[0x47u8; 64]).unwrap(); // TS sync bytes, no FMKV magic
-            s.shutdown(std::net::Shutdown::Both).unwrap();
+            s.shutdown(std::net::Shutdown::Write).unwrap();
+            // Park until the server closes, so no RST can overtake the data.
+            let _ = s.read(&mut [0u8; 1]);
         });
         let err = match NetworkStream::accept_from(listener) {
             Ok(_) => panic!("missing FMKV header must error, not silently accept"),