Cover the XPS 16 with the XPS 14 speaker tuning

Reported to suit the XPS 16 as well, so the tuning now matches both machines and
the directory is named for the pair rather than the one model.

Gating moves from the DMI product name to the product SKU, which is what Dell keys
the Cirrus speaker firmware on -- 10280db9 for the XPS 14, 10280dba for the XPS 16
-- so it identifies the speaker hardware itself instead of a marketing name. SKUs
are compared as whole values, not substrings, so this cannot widen to the rest of
the XPS line the way a short product-name match would: product_family on these
machines is "Dell Laptops".

match_sku and match_dmi are now lists, letting one tuning name every model it
covers. A plain string still works as a single entry.

The measurements in tuning.conf were taken on the XPS 14 (0DB9). The XPS 16 is
covered on report rather than measurement, and tuning.conf and the graph both say
so, because the profile's bass lift and high-pass were fitted against one
machine's excursion and distortion limits.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

bin/omarchy-audio-tuning

@@ -41,6 +41,29 @@ sink_matching() {
   pactl list sinks short 2>/dev/null | awk -v p="$1" '$2 ~ p {print $2; exit}'
 }
 
+# Dell keys its Cirrus speaker firmware on the DMI product SKU, which makes it the
+# most precise identifier available for these machines -- narrower than a product
+# name, and it distinguishes models whose names differ only by marketing. Compared
+# case-insensitively against an exact SKU, never a substring, so a tuning cannot
+# accidentally widen to a whole product line.
+sku_matches() {
+  local sku want
+  sku="$(cat /sys/class/dmi/id/product_sku 2>/dev/null)"
+  [[ -n $sku ]] || return 1
+  for want in "$@"; do
+    [[ ${sku,,} == "${want,,}" ]] && return 0
+  done
+  return 1
+}
+
+dmi_matches() {
+  local want
+  for want in "$@"; do
+    omarchy-hw-match "$want" 2>/dev/null && return 0
+  done
+  return 1
+}
+
 # Print the tuning directory matching this laptop, if any. Matching is data, not
 # code: a tuning declares the DMI string it belongs to and the sink it expects, so
 # most tunings can be added as a directory with no new script. A tuning whose
@@ -50,7 +73,7 @@ tuning_match() {
   for dir in "$tunings_dir"/*/; do
     [[ -r $dir/tuning.conf ]] || continue
 
-    unset match_dmi match_command sink_pattern
+    unset match_dmi match_sku match_command sink_pattern
     # shellcheck disable=SC1090
     source "$dir/tuning.conf"
 
@@ -58,11 +81,16 @@ tuning_match() {
     # the ISO chroot with no audio server, and a match that depended on a present
     # sink would come back empty there -- so the machine would get neither the LV2
     # dependency nor the tuning, and nothing would retry.
+    # A tuning may list several models it has been validated on. match_dmi and
+    # match_sku are arrays, so a plain string still works as a single entry.
     if [[ -n ${match_command:-} ]]; then
       "$match_command" 2>/dev/null || continue
+    elif [[ -n ${match_sku:-} ]]; then
+      sku_matches "${match_sku[@]}" || continue
+    elif [[ -n ${match_dmi:-} ]]; then
+      dmi_matches "${match_dmi[@]}" || continue
     else
-      [[ -n ${match_dmi:-} ]] || continue
-      omarchy-hw-match "$match_dmi" 2>/dev/null || continue
+      continue
     fi
 
     # Required whichever way the tuning matched: the graph's target sink is