fleetd #550: replace shasum with a portable hash256 helper, add a Linux CI job for the shell suite

jar_id() in redeploy-fleetd.sh called shasum directly, which does not exist on GNU coreutils
Linux (Debian/Ubuntu/etc.) — there it silently reported an existing jar as "absent" with exit 0,
because the missing command made `cut` succeed on empty input and pipefail's failure was then
swallowed by the `|| echo "absent"` fallback. The shell test suite hit the same tool at
test-redeploy-fleetd.sh:298-299 and died at exit 127 with zero FAIL lines printed — the same shape
as a clean pass on the one channel anyone would check.

Adds one hash256() helper (prefer sha256sum, fall back to shasum -a 256, same idiom already used
in probe-member-credentials.sh) and points jar_id and the test suite's own reference hash at it.
jar_id now has three distinct answers instead of two: absent, a hash, or "unhashable" when neither
hasher is on PATH — "absent" is never used for a file that exists.

Adds a CI job (shell-tests) that runs scripts/test-redeploy-fleetd.sh on ubuntu-latest, gated on
the step's own exit code rather than a FAIL-line count, since a suite that dies before running is
exactly what a green run also looks like by that count.

New tests: test_jar_id_reports_unhashable_when_no_hasher_on_path (stubbed PATH with neither
hasher) and test_no_unguarded_macos_only_hasher_calls (a shape check across every script under
scripts/, not named lines — #545 already showed this idiom spreading from two sites to six).

scripts/redeploy-fleetd.sh

@@ -140,11 +140,35 @@ ok()   { printf '   ok    %s\n' "$*"; }
 warn() { printf '   WARN  %s\n' "$*"; }
 die()  { printf '\n   FAIL  %s\n\n' "$*" >&2; exit 1; }
 
+# fleetd #550 — shasum is macOS-only (it ships with Perl, which Debian/Ubuntu/etc. do not install
+# by default); GNU coreutils (every mainstream Linux distro) ships sha256sum instead and has no
+# shasum at all. Prefer sha256sum, fall back to shasum -a 256 — same idiom as
+# probe-member-credentials.sh's `hasher` selection — and when NEITHER is on PATH, say so plainly.
+# That third answer matters: without it, a missing hasher makes `cut` succeed on empty input, and
+# under `set -o pipefail` the pipeline as a whole still fails, so a caller's own `|| echo "absent"`
+# then reports a file that is right there as though it were gone. `hash256` never does that — it
+# only ever hashes or says it could not.
+hash256() {
+  local f="$1"
+  if command -v sha256sum >/dev/null 2>&1; then
+    sha256sum "$f" | cut -c1-12
+  elif command -v shasum >/dev/null 2>&1; then
+    shasum -a 256 "$f" | cut -c1-12
+  else
+    echo "unhashable"
+  fi
+}
+
 # Reports the hash of $JAR by default, or of whatever path is passed — used to report the STAGED
 # jar right after a build (before it has been swapped in) without ever changing what a bare
 # `jar_id` (no args) means: the live path, $JAR. --check and the final "pid ..., jar ..." line
 # both call it with no args on purpose, so neither can ever be fooled by a leftover staged file.
-jar_id() { local f="${1:-$JAR}"; [ -f "$f" ] && shasum -a 256 "$f" | cut -c1-12 || echo "absent"; }
+# fleetd #550 — THREE distinct answers now, not two: `[ -f "$f" ]` already separates "the jar is
+# not there" (-> "absent") from "the jar is there"; for the second case, hash256 itself separates
+# "hashed it" (a 12-char hex string) from "could not hash it" (-> "unhashable", when no hasher is
+# on PATH). "absent" must never be the answer for a file that exists — that conflation, on Linux,
+# was the whole defect this ticket fixes.
+jar_id() { local f="${1:-$JAR}"; [ -f "$f" ] && hash256 "$f" || echo "absent"; }
 running_pid() { pgrep -f "$PATTERN" || true; }
 
 # fleetd #493 — three small, independently testable pieces of "never build into the path a