fix(hwmon): the SATA temperature walk used the input struct's layout

`SMART_RCV_DRIVE_DATA` replies with `SENDCMDOUTPARAMS`, whose payload begins
after `cBufferSize` and a `DRIVERSTATUS` — sixteen bytes. The attribute walk
started at `32 + 2`, which is the *input* struct's layout: `SENDCMDINPARAMS`
carries an extra `bReserved[3]` and `dwReserved[4]`, and its buffer really
does begin at 32. Borrowing that for the reply put every attribute id
sixteen bytes into the neighbouring entry.

Found by auditing the crate's remaining offset-based parsers after the NVMe
SMART fix, which was the same shape one file over.

The hand-rolled attribute walk is gone rather than corrected.
`disk::ata_smart` already parses this exact 512-byte structure from ACS-4
offsets and refuses one whose checksum does not validate, and it is the
parser the Windows disk path uses. Two parsers for one layout is how one of
them stays wrong; the temperature now comes from
`AtaSmartData::temperature_celsius`, so a bad buffer is declined instead of
yielding a plausible number.

The offset is `offset_of!` on a declared `SendCmdOutParams` rather than a
literal, with a compile-time assertion pinning it to the sixteen that
ntdddisk.h gives. Being straight about what that is worth: it means a later
edit to a field cannot shift the payload without failing to compile. It does
not confirm my reading of the header. **Nothing here can — this machine has
three NVMe drives and no SATA drive, so this code does not run.** It joins
the ATA path in open work item 3 as changed-but-unexercised, and one run of
`cargo run --example disk_monitor` against `smartctl -A` on a SATA drive
settles both.

NVMe drive temperatures are unaffected and still read 41.9, 42.9 and 54.9°C
through the separate NVMe path, which is the check that this change is
confined to the SATA branch.

Verified: fmt, clippy, both cross-target checks, 37 disk unit tests.

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