Panic for `file` while using base

[wooffie]

• Note that this crate implements the URL Standard not RFC 1738 or RFC 3986

Describe the bug

Testcase:

#[test]
fn test_file_base_panic() {
    let base_url = Url::parse("file:///w:/a:").unwrap();
    Url::options().base_url(Some(&base_url)).parse("file:..");
}

Backtrace:

thread 'test_file_base_panic' (377458) panicked at url/src/parser.rs:1321:21:
assertion failed: self.serialization.as_bytes()[segment_start - 1] == b'/'
stack backtrace:
< skipped >
  19:     0x57a3a138611c - core::panicking::panic::hb515f22c0e98143a
                               at /rustc/f8297e351a40c1439a467bbbb6879088047f50b3/library/core/src/panicking.rs:145:5
  20:     0x57a3a12cfb59 - url::parser::Parser::parse_path::h69b46743c9367ec2
                               at /home/wooffie/work/upstream/rust-url/url/src/parser.rs:1321:21
  21:     0x57a3a12cd0d9 - url::parser::Parser::parse_file::h88e81c17dec524c5
                               at /home/wooffie/work/upstream/rust-url/url/src/parser.rs:659:46
  22:     0x57a3a12d3896 - url::parser::Parser::parse_with_scheme::h31ca21d8147c599c
                               at /home/wooffie/work/upstream/rust-url/url/src/parser.rs:446:22
  23:     0x57a3a12d637d - url::parser::Parser::parse_url::hadfb176b92197e15
                               at /home/wooffie/work/upstream/rust-url/url/src/parser.rs:382:25
  24:     0x57a3a12af420 - url::ParseOptions::parse::hf1b29cfaa662d5f3
                               at /home/wooffie/work/upstream/rust-url/url/src/lib.rs:314:10
  25:     0x57a3a124735b - unit::test_file_base_panic::h46e4b9e042615051
                               at /home/wooffie/work/upstream/rust-url/url/tests/unit.rs:725:46

ref #838

[earfman]

Root cause: pop_path (url/src/parser.rs) refuses to remove the last path segment when it is shaped like a normalized Windows drive letter — but it applied that exemption to any last segment, not just one in drive position. For file:///w:/a:, the last segment a: looks like a drive letter, so joining .. / file:.. never pops it; .. is then appended without a separating /, and the .. branch's debug_assert!(...[segment_start - 1] == b'/') fires — a panic in debug, and the wrong path in release.

Per the WHATWG "shorten a URL's path" step, the drive-letter exemption applies only when the path has a single segment and path[0] is the drive letter. The fix restricts the guard to segment_start == path_start + 1 (drive position), so a: in /w:/a: is popped while a genuine drive letter such as file:///a:/.. is preserved.

PR with the fix — a regression test, WHATWG-oracle verification, and parse-time guards that the drive-position case is not regressed: #1143