fleetd #550: pin hash256's algorithm against a literal SHA-256 test vector

test_jar_id_defaults_to_live_and_reports_explicit_path's reference hash is computed by calling
hash256 itself (needed so it doesn't call the Linux-crashing bare shasum directly). That made
subject and reference the same instrument: they agree no matter which algorithm hash256 actually
runs, so a mutation swapping both of hash256's arms for the wrong algorithm was invisible to the
suite.

Adds test_hash256_computes_a_real_sha256, pinned against the published SHA-256 test vector for the
3-byte input "abc" (ba7816bf8f01...), written as a literal constant rather than computed by any
hasher at test time. Verified the constant myself both ways (sha256sum and shasum -a 256) before
writing it in.

scripts/test-redeploy-fleetd.sh

@@ -335,6 +335,26 @@ test_jar_id_defaults_to_live_and_reports_explicit_path() {
   assert_equals "$staged_hash" "$explicit_result" "jar_id \"\$JAR_STAGED\" must report the hash of the staged jar, not fall back to \$JAR"
 }
 
+# fleetd #550 — closes a gap the test above leaves open. That test's own reference hash is now ALSO
+# computed by calling hash256 (needed for item 2: the old bare macOS-only-hasher call there was the
+# Linux crash), so its subject (jar_id, via hash256) and its reference (also hash256) share one
+# instrument — they agree no matter which algorithm hash256 actually runs, so a mutation that swaps
+# BOTH of hash256's arms for the wrong algorithm is invisible to it. This test's expected value
+# comes from neither hasher: it is the published SHA-256 test vector for the 3-byte input "abc"
+# (no trailing newline), written here as a literal constant, so it can still tell "hashed
+# correctly" from "hashed, just with the wrong algorithm" — which is what this whole ticket is
+# about.
+test_hash256_computes_a_real_sha256() {
+  local dir f result
+  dir="$TMP/hash256-known-vector"; mkdir -p "$dir"
+  f="$dir/abc.txt"
+  printf 'abc' > "$f"
+  result="$(hash256 "$f")"
+  # SHA-256("abc") = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, the standard
+  # FIPS 180 test vector — first 12 hex chars, matching hash256's own `cut -c1-12`.
+  assert_equals "ba7816bf8f01" "$result" "hash256 of the literal 3-byte input 'abc' must be the known SHA-256 prefix, not some other algorithm's"
+}
+
 # fleetd #517 — jar_id()'s "absent" branch was unpinned by any test: the existing test above (#511)
 # proves both halves of the present-file contract but never exercises the missing-file path. This
 # word matters more than a string usually would: "absent" is the #413 signal that a `mvn clean`
@@ -1236,6 +1256,7 @@ test_count_daemon_pids
 test_assert_single_daemon_accepts_one_pid
 test_assert_single_daemon_rejects_two_pids
 test_jar_id_defaults_to_live_and_reports_explicit_path
+test_hash256_computes_a_real_sha256
 test_jar_id_reports_absent_for_missing_file
 test_jar_id_reports_unhashable_when_no_hasher_on_path
 test_stage_built_jar_moves_off_live_path