deploy-standard-workflows commits an EMPTY stub and reports OK when base64 encoding fails (macOS) #1268

Problem

scripts/lib/standards-deploy.sh (~L159) encodes the file to commit with:

encoded=$(base64 -w 0 "$local_file" 2>/dev/null || base64 -b 0 "$local_file")

On macOS both forms fail (-w is unsupported; the fallback passes the file positionally, which that base64 rejects and answers with its usage text). encoded ends up empty, the Contents API commit goes through with empty content, and the script prints OK … opened <PR>.

Evidence (2026-10-09)

scripts/deploy-standard-workflows.sh --force --workflow dev-lead.yml --repo <repo> run from macOS at main 2e3d523 opened:

• petry-projects/broodminder-data#179 — .github/workflows/dev-lead.yml +0/−74
• petry-projects/empower-personal-dashboard#73 — .github/workflows/dev-lead.yml +0/−74

Each would have blanked the dev-lead caller stub. Both were closed unmerged. The only visible symptom during the run was a stray base64 usage message above the OK line. The scheduled Standards Deploy workflow runs on Linux and is not affected.

Expected

• Encoding is portable (for example read the file on stdin: base64 < "$f" | tr -d '\n').
• The deploy fails closed: if the encoded payload is empty while the source file is not, or the encode command exits non-zero, the script reports an error, sets a failing exit status, and commits nothing.
• A bats test covers the empty-payload case with base64 stubbed to fail.

Found while working on #1267 (Standards sweep and compliance audit accept a stale channel major). Not labelled dev-lead; label it when you want it picked up.

Leftover from the two runs: a standards-sync/workflows-20261009 branch in each of the two repos, holding the empty-file commit.