feat(hardware): hide dual-sensor webcam IR node (fixes dark image)

A built-in RGB+IR webcam (common on recent ThinkPads, e.g. the T14s AMD
Gen 4) exposes its IR face-unlock sensor as a second, identically-named
"Integrated Camera"; apps that pick it show a dark, 8-bit-greyscale
image. nomarchy.hardware.camera.hideIrSensor disables that node on the
V4L2 PipeWire path (WirePlumber monitor.v4l2.rules) so only the colour
camera is offered, matched by card name (overridable irMatch).

- libcamera is left untouched: an external camera you plug in is never
  affected, and surgical internal-only libcamera scoping isn't possible
  (its distinguishing props bind after the monitor rule runs).
- Only the PipeWire node is hidden; the kernel /dev/video* stays open,
  so Howdy face-unlock still reads the IR sensor directly.
- The installer's hardware-db.sh auto-detects a paired RGB+IR webcam
  from /sys/class/video4linux/*/name and bakes the toggle into
  system.nix; commented example added to the downstream template.

Validated live on a T14s: collapses the four enumerated "Integrated
Camera" entries to one colour source; the exact shipped regex disables
the IR node (confirmed in the WirePlumber log) and leaves libcamera
intact.

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

docs/ROADMAP.md

@@ -428,6 +428,74 @@ how to override it. Items marked ✓ are shipped.
     distro-wide regardless).
   Sub-items here can graduate into their own roadmap entries as they're
   scoped; the unifying work is the detection + `nomarchy.hardware.*` surface.
+- **Webcam support & tuning:** improve out-of-the-box webcam behaviour.
+  Motivating case — on the ThinkPad T14s AMD Gen 4 the camera shows a dark,
+  low-quality image. **Diagnosed on hardware (2026-06-26)**, and it's *not* what
+  the first cut of this item guessed (UVC default-controls tuning vs a MIPI/
+  libcamera gap):
+  - The camera is a **USB UVC** module (Chicony `04f2:b7c0`, `uvcvideo`) and is
+    **dual-sensor** — `video0` Color (MJPG, up to 2592×1944 / 1080p) + `video2`
+    **IR** (8-bit `GREY` only, the face-unlock sensor). The AMD IPU `[1022:1502]`
+    is present on PCI but **unused** (the camera enumerates over USB, not the
+    MIPI/ISP path), so the libcamera-software-ISP branch is moot on this machine.
+  - The **raw color capture is fine**: at factory defaults with auto-exposure,
+    `/dev/video0` measures luma ≈130/255 *from the first frame* (no AE ramp, not
+    dark); forcing manual exposure made it *worse*. So there is **no v4l2 control
+    default to bake** — the speculated `v4l2-ctl`-tuning / udev-oneshot fix is the
+    wrong tree.
+  - **Real cause is the consumption path.** PipeWire/WirePlumber exposes the
+    device through **both** backends at once — two `[v4l2]` sources (node 144 =
+    `/dev/video0` Color, node 146 = `/dev/video2` **IR**) **plus** two
+    `[libcamera]` nodes (Color + IR) — and the IR sensor is presented as an
+    **indistinguishable** "Integrated Camera". So an app's camera picker shows up
+    to *four* identical entries, and choosing the IR one yields a black/dark
+    monochrome frame; the libcamera path can also negotiate the low-res `YUYV`
+    640×480 mode ("bad quality"). The default source is the color node, so apps
+    that don't let you choose are fine — the breakage is selecting (or an app
+    auto-selecting) the wrong node.
+  - **Fix — validated live on hardware (2026-06-26).** Two WirePlumber 0.5
+    drop-ins collapse the four entries to one clean color camera, confirmed via
+    `wpctl status` (before: 2 v4l2 + 2 libcamera incl. both IR nodes → after:
+    **1** v4l2 source = `/dev/video0` color, **0** libcamera):
+    1. **Hide the IR node** — `monitor.v4l2.rules` matching the IR sensor →
+       `node.disabled = true`. (Tested by card name `~.*Integrated I`; the
+       **shipping** match should key on the more robust, vendor-neutral heuristic
+       of a **`GREY`-only / no-color-format** node, since other vendors' IR cards
+       are named differently.)
+    2. **Drop the duplicate backend** — `wireplumber.profiles.main.monitor.libcamera
+       = disabled`, since a plain UVC cam is fully covered by v4l2 (also kills the
+       libcamera low-res-`YUYV` path).
+    **Drawbacks / design constraints for the module:**
+    - Rule 2 (libcamera off) is only safe **when a UVC camera exists** — on a
+      MIPI/IPU-only machine (no UVC fallback) it would kill the camera entirely,
+      so it **must be conditional on detection**, not blanket. Rule 1 (IR-hide)
+      is broadly safe. Exactly the `nomarchy.hardware.*`-gated targeting the
+      parent item calls for.
+    - **Face-unlock is *not* broken:** `node.disabled` only hides the PipeWire
+      node; the kernel `/dev/video2` stays openable, so Howdy (which reads the IR
+      device directly, bypassing PipeWire) still works.
+    A true MIPI/IPU software-ISP camera with no UVC fallback stays a separate
+    future item.
+  - **Shipped (2026-06-27):** `nomarchy.hardware.camera.hideIrSensor` (+ an
+    overridable `irMatch` regex) in `modules/nixos/hardware.nix` emits rule 1 via
+    `services.pipewire.wireplumber.extraConfig`; the installer's `hardware-db.sh`
+    auto-detects a paired RGB+IR webcam (from `/sys/class/video4linux/*/name`)
+    and bakes the toggle into `system.nix`, with a commented example in the
+    downstream template. **Decision: v4l2 IR-hide only — libcamera is left
+    untouched** so an external camera you plug in is never affected. Surgical
+    internal-only libcamera scoping proved impossible: the distinguishing device
+    props (`api.libcamera.location`, `device.product.name`) bind *after* the
+    monitor rule runs, and the only early-matchable prop (`device.api`) is
+    all-or-nothing — so a broad libcamera-off was the only option and was rejected
+    as the blunt instrument it is (external USB cams are UVC and keep working via
+    v4l2 regardless). Verified: installer detection fires on the T14s; the
+    generated drop-in's serialized content is valid WP-0.5 config; and the exact
+    shipped `irMatch` was re-confirmed live (1 V4L2 source = the colour
+    `/dev/video0`, libcamera untouched, IR node disabled in the WirePlumber log).
+    Remaining: an on-Nomarchy end-to-end check; optional `v4l-utils` +
+    `cameractrls` for the rare genuine-tuning case; and a follow-up for
+    portal/Flatpak apps that consume the libcamera path (where the internal IR is
+    still listed, since libcamera stays on).
 - **Opt-in services & integrations:** the counterpart to the opt-*out*
   application suite above — heavier or more personal integrations shipped
   **off by default**, each a `nomarchy.services.<name>.enable` toggle a