Two host assumptions the build scripts had never left this machine to test [build]

Both surfaced on the first CI run and both are real portability defects,
not workflow mistakes.

macOS: /usr/bin/lockf is absent on macOS 14, and therefore on the
macos-14 runner, while it is present on 26. zsh reported "no such file or
directory" and the `||` branch turned that into "another macOS AudioHub
build is already running" — on a fresh VM where nothing else was running
at all. The lock is now taken when lockf exists and its absence is
announced instead of swallowed, because degrading is only defensible on
a single-use runner that builds once, never on a developer machine.

Windows: `npm --prefix <dir> install` redirects where packages are
written, but which package.json npm READS is version-dependent. The
runner's npm kept reading the current directory and failed with ENOENT on
the repository root, while the same line worked on a developer box with
an older npm. Running npm from inside the frontend directory has no such
ambiguity.

Author: Score2

app/build-app.sh

@@ -45,9 +45,25 @@ else
   [[ ! -L "$BUILD_LOCK" ]] || die "refusing a symlinked macOS build lock: $BUILD_LOCK"
   exec 8>>"$BUILD_LOCK"
   /bin/chmod 0600 "$BUILD_LOCK"
-  /usr/bin/lockf -s -t 0 8 \
-    || die "another macOS AudioHub build is already running"
-  export AUDIOHUB_MACOS_BUILD_LOCK_PATH="$BUILD_LOCK"
+  # `lockf` is not on every macOS: it is absent from macOS 14 (and so from the
+  # macos-14 GitHub runner) and present on 26. Without this check its absence
+  # surfaced as `no such file or directory` followed by the `||` branch —
+  # i.e. the build reported "another build is already running" on a machine
+  # where nothing else was running at all.
+  #
+  # Degrading here is safe for exactly one reason, and it is worth stating:
+  # this lock serialises two builds on the SAME checkout, and the only hosts
+  # missing lockf are fresh single-use CI runners that build once. It is not
+  # safe to extend that reasoning to a developer machine, which is why the
+  # absence is announced rather than swallowed.
+  if [[ -x /usr/bin/lockf ]]; then
+    /usr/bin/lockf -s -t 0 8 \
+      || die "another macOS AudioHub build is already running"
+    export AUDIOHUB_MACOS_BUILD_LOCK_PATH="$BUILD_LOCK"
+  else
+    print -ru2 -- "[audiohub] WARNING: /usr/bin/lockf is missing on this host; \
+building without the concurrent-build lock. Do not run two builds at once."
+  fi
 fi
 
 TRIPLE="$(rustc -vV | awk '/^host: /{print $2}')"

scripts/build-windows-installer.ps1

@@ -337,7 +337,18 @@ Step 'Windows-native frontend dependencies'
 # node_modules, so merely checking that the directory exists is insufficient:
 # a previous checkout can leave a valid-looking but incomplete dependency
 # tree. `npm install` is lockfile-aware and cheap when the tree is current.
-Invoke-Checked { & $Npm --prefix $FrontendDir install --no-audit --no-fund } 'npm install'
+# Run npm FROM the frontend directory rather than relying on --prefix.
+# `--prefix` redirects where packages are written, but which package.json npm
+# READS is a version-dependent detail: on the GitHub windows runner's npm it
+# kept reading the current directory and failed with ENOENT on the repository
+# root's (non-existent) package.json, while the same command worked on a
+# developer box with an older npm. Push-Location has no such ambiguity.
+Push-Location $FrontendDir
+try {
+    Invoke-Checked { & $Npm install --no-audit --no-fund } 'npm install'
+} finally {
+    Pop-Location
+}
 
 # cargo-about resolves the union of target-specific dependency graphs while it
 # runs frozen. A target-qualified fetch only downloads that one graph, so a