Add gather-hardware-info.sh — auto-detects most report fields

Reads /proc, /sys, and common CLI tools (lscpu, lsblk, lspci, lsusb) to
print a YAML block matching data/schema.json: device model (DMI on x86,
/proc/device-tree/model on ARM SBCs), form factor (best-effort — battery
presence, DMI chassis type, device-tree presence), CPU, RAM, root storage
type/size, WiFi chip (PCI, then USB, then falls back to driver name rather
than guessing wrong), ethernet. Fields it can't detect (archy_version,
install_method, status) are left as clearly-marked TODOs rather than
guessed. Local-only — no network calls, changes nothing.

Tested for real on this box (a QEMU VM): correctly identified it as a VM,
correctly fell back to "other" with a TODO for form_factor rather than
guessing, output validated as parseable YAML. Passes shellcheck clean.

Linked from the homepage, report.html, and CONTRIBUTING.md.

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

CONTRIBUTING.md

@@ -1,6 +1,10 @@
 # Contributing to ArchyHCL
 
-Two ways to add a report, pick whichever's easier for you.
+Two ways to add a report, pick whichever's easier for you. Either way,
+running [`gather-hardware-info.sh`](https://hcl.archipelago-foundation.org/gather-hardware-info.sh)
+on the machine you tested first is the easiest way to get accurate
+CPU/RAM/storage/WiFi-chip values — it's local-only (reads `/proc`/`/sys`,
+no network calls), read it before you run it like any script.
 
 ## Option A — use the report form (no git needed)
 
@@ -31,8 +35,9 @@ supported no-git path, not the raw "New Issue" button.)
    This fails loudly (and tells you exactly which field) if anything's
    wrong — same idea as [archy](https://source.archipelago-foundation.org/lfg2025/archy)'s
    own `scripts/validate-app-manifest.sh`.
-4. Open the PR. Once merged, `scripts/build.py` regenerates `site/data.json`
-   and the site picks it up.
+4. Open the PR. Once merged, deployment is automatic — a CI job rebuilds
+   `site/data.json` and pushes it live within seconds, no manual step
+   needed.
 
 ## Updating an existing report
 
@@ -44,10 +49,12 @@ report is.
 
 ## What makes a good report
 
-- Be exact about the WiFi chip if you can (`iwconfig`/`lspci` on Linux,
-  Device Manager on Windows if you dual-booted to check). "Realtek" alone
-  isn't as useful as "Realtek RTL8821CE" — chip-specific driver issues are
-  the single most common thing this list exists to surface.
+- Be exact about the WiFi chip if you can (`gather-hardware-info.sh` above
+  gets this right on most Linux hardware; `iwconfig`/`lspci` by hand
+  otherwise, Device Manager on Windows if you dual-booted to check).
+  "Realtek" alone isn't as useful as "Realtek RTL8821CE" — chip-specific
+  driver issues are the single most common thing this list exists to
+  surface.
 - If `status` is `partial` or `broken`, describe *what* broke and *how you
   noticed* (crash on boot? WiFi drops under load? specific app won't
   start?) — "doesn't work" isn't actionable for the next person.