fix(edid): an interlaced mode reported field lines as a resolution

`simon profile show display` reported an AV receiver's preferred mode as
`1920×540 @ 60.05 Hz` — a resolution no equipment has. The EDID
specification stores vertical active as **lines per field** for an
interlaced timing, and the parser never read byte 17 of the descriptor,
whose bit 7 says which. The real mode is 1920×1080 interlaced at a 60 Hz
field rate: 1080i60.

Confirmed against the raw bytes in the registry rather than inferred. The
descriptor is `01 1D 80 18 71 1C 16 20 …  9E`: pixel clock 0x1D01 × 10 kHz =
74.25 MHz, h_active 1920, v_active 540, flags 0x9E with bit 7 set.

Frame lines are what a reader means by a resolution, so those are reported
now, marked with an `i`. The refresh is left as the field rate, because that
is the number equipment is labelled with — 1080i60 means sixty fields, not
thirty.

The two progressive displays are unchanged at 3440×1440 @ 59.97 Hz, which is
the check that the fix is narrow.

The test uses the receiver's real eighteen descriptor bytes rather than a
synthesised fixture, following what the NVMe offsets cost: a fixture built
by the same hand as the parser agrees with the parser. It was confirmed to
fail against the old code first — `left: 540, right: 1080` — before being
trusted, and a companion test pins that a progressive mode is not doubled by
the same path.

Found by auditing the crate's other offset-based binary parsers after the
NVMe SMART fix. `ata_smart.rs` remains the one that cannot be checked here,
for want of a SATA drive.

Verified: fmt, clippy, both cross-target checks, 6 edid unit tests.

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