Fill diagnostic gaps: staged network, Bluetooth/input, and update health

[deucebucket]

Problem

Research identified three broad areas that are only partially automated: network failures above the Wi-Fi link, Bluetooth/HID/input-device lifecycle, and SteamOS update/slot/deployment health.

Scope

Add three read-only modules or clearly separated sections with a shared evidence/access schema.

Network stages

Interface/driver → association → address → default route → gateway → DNS → captive portal/VPN → Steam service. Redact network identities by default.

Bluetooth and input

Controller presence, driver/bus, Steam Input visibility, Bluetooth service/adapter/pair/connect state, bounded HID/USB errors, resume timing, and privacy-safe event metadata. Never record keystrokes or raw input values.

Update health

Current/previous SteamOS build and slot, kernel/BIOS/client channel, update service failures, immutable-root state, free space, and previous-image contrast. Do not mutate slots or run system-wide package replacement.

Acceptance criteria

• Each stage is reported as pass/fail/inaccessible/not-applicable without equating missing evidence with health.
• Same-incident timestamps integrate with the unified timeline.
• LCD/OLED, SteamOS-only, Windows, docked, and Rescue applicability is explicit.
• Fixtures cover linked-no-internet, DNS-only failure, Wi-Fi device loss, Bluetooth resume loss, one-control config fault, input hardware suspicion, failed update, previous-image recovery, and full disk.
• Wiki and DeckMD routes consume the same normalized vocabulary.
• No raw input capture, network identity publication, package installation, or automatic rollback.

Docs

docs/wiki/Network-and-Resume-Problems.md, docs/wiki/Controls-Bluetooth-and-Input.md, and docs/wiki/Recovery-and-Escalation.md.