🐛 Decode the whole SMBIOS memory-type table, not three values of it

[manupawickramasinghe]

Merge order: #32 (unbreaks currently-red CI) → #28 → #29 → #30 → #31. Each is independently reviewable; the order just keeps the checks readable.

The bug

The System Summary reported the literal string "DRAM SDRAM" as the memory type on most current laptops.

Two bugs compounding. Win32_PhysicalMemory.SMBIOSMemoryType was decoded for exactly three values:

let mem_type = match u(r.get("SMBIOSMemoryType")) {
    Some(26) => "DDR4",
    Some(34) => "DDR5",
    Some(24) => "DDR3",
    _ => "DRAM",
};

Every soldered-memory machine reports an LPDDR code (0x1B–0x1E, 0x23), so that fallback covered most portable hardware sold today. summary_window.rs then appended " SDRAM" to whatever it was handed, turning the fallback into nonsense.

The fix

smbios_memory_type decodes the full DMTF table, codes 0x01–0x24, cross-checked against dmidecode's dmi_memory_device_type. That adds:

• LPDDR, LPDDR2, LPDDR3, LPDDR4, LPDDR5 — the laptop gap
• HBM, HBM2, HBM3
• the older SDRAM / RDRAM / DDR / DDR2 / FB-DIMM codes

0x15–0x17 are Reserved rather than memory types, so they deliberately fall through along with everything unassigned. A test walks every code from 0x01 to 0x24 and asserts that only those three reach the unknown path, so the coverage claim is checked rather than asserted.

An unassigned code reports as Unknown (type 0x25) rather than being flattened into a wrong name. DMTF assigns new codes as memory generations ship, and the raw number is what lets someone look one up.

The " SDRAM" suffix now goes through memory_type_label, which applies it only to the DDR and LPDDR families — HBM3 and Unknown are left alone.

Verification

• 7 new tests, all passing. They take the raw code rather than reading WMI, so they run on every CI leg — including the aarch64 one from ✨ Build and publish arm64 Linux artifacts #29.
• Full suite: 89 passed, 0 failed.
• cargo clippy --all-targets -- -D warnings clean across "", web, gui, tui, gui,web.
• Verified on real hardware — a DDR5 desktop still reports DDR5:

Memory
  P0 CHANNEL A/DIMMA1  16 GB DDR5
  P0 CHANNEL B/DIMMB1  16 GB DDR5

One note for reviewers: memory_type_label needs #[allow(dead_code)] because only the GUI renders it. Without that the headless legs fail on -D warnings — caught locally by running the same feature matrix CI does, not by the default build.

Adjacent, deliberately not fixed here

The same Memory panel infers channel count from the module count (summary_window.rs), so four DIMMs on a mainstream dual-channel board report "Quad-Channel", and 3/6/8/12-module HEDT and server configurations report nothing at all. Different bug, different fix — worth its own PR.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[manupawickramasinghe]

The Windows and macOS checks here are red for a reason that has nothing to do with this PR: both fail at the Clippy step on error: using chunks_exact with a constant chunk size, inherited from master. That is Rust 1.98's new clippy::chunks_exact_to_as_chunks lint meeting CI's -D warnings — see #32, which fixes it.

Confirmed by reading the failing logs: the lint fires in src/source/firmware.rs (Windows) and src/source/macos/dvfs.rs (macOS), neither of which this PR touches. The Linux leg, where neither file compiles, is green.

Merge #32 first and these go green on a rebase.