fix(secret): store macos secrets in keychain via stdin - #436

Adversarial security + QA review, both with live macOS reproduction against the real /usr/bin/security binary (not simulated), plus an independent re-run of the full test suite.

The core security claim is genuine and verified, not just asserted. Reproduced live: values never appear in argv/process table; security -i does NOT perform shell-style $VAR/backtick expansion inside double-quoted tokens on this macOS build (tested with a literal $VAR and backtick-bearing value — round-tripped byte-for-byte, no expansion); a failed keychain write correctly returns 1 and never falls through to a silent plaintext write. ACQ_SECRET_ALLOW_ARGV is fully removed with zero stale references anywhere in the tree. The stricter [A-Za-z0-9_-] service/sandbox validation causes no regression against any real service name used anywhere in the codebase or docs.

One real, non-blocking security finding. _acq_secret_security_i_quote() escapes only \ and " — a raw embedded newline in the secret value is not escaped, and I confirmed live this WOULD let a value inject a second security -i command (e.g. a rogue add-generic-password) if such a value ever reached the writer. Every actual code path is safe today because the value is first read via a single-line IFS= read -r (structurally incapable of holding an embedded \n) — confirmed for the TTY-masked read, the piped-stdin read, and the acq_secret_import path (which additionally has an explicit newline/TAB rejection, verified enforced in code, not just asserted in the docstring). The one exception: the test-only ACQ_SECRET_TEST_VALUE escape hatch has no explicit gate — currently unreachable in production (no production path sets it), but if a future change ever wires a production secret through that same branch, the newline would silently truncate rather than being rejected. Recommend a follow-up issue applying the same explicit-rejection pattern _acq_import_value_is_storable already uses.

Test-result claim correction: the PR body states 404/404 for the full suite. I independently reproduced 401/404 (confirmed identically by both reviewers) — the 3 failures are in files byte-identical to main (30-dispatch-routing.bats, 70-msb-backend.bats, 90-sbx-startup-kit.bats) and reproduce the same way against main itself, so they're pre-existing host-environment flakes (real-git-identity env leakage in my case), not a regression from this diff. The targeted file (71b-msb-secret-store-backends.bats) is a clean 9/9, matching the PR body.

One genuine, previously-undocumented limitation found: security find-generic-password -w hex-mangles the read-back of any value containing control characters or non-ASCII bytes (verified: the write is byte-correct via -g's raw hex dump; only the -w read formatting is affected). Low-probability given acq secrets are API tokens (overwhelmingly ASCII), but neither the bats stub, the probe script, nor the docs mention it — worth a doc note or tracked follow-up.

Everything else verified clean: probe script and production quoting functions are byte-identical (diffed directly — the "verified live on macOS 26.6.2" claim genuinely validates the shipped code, not a divergent scheme); ADR-0011/BACKEND_GUIDE.md's legacy-file-fallback description matches the live code path exactly; no other doc anywhere in the tree describes the old ALLOW_ARGV-gated behavior.

Two non-blocking follow-ups recommended (the ACQ_SECRET_TEST_VALUE gate, the non-ASCII read-side caveat); neither blocks this PR, which is a well-engineered, correctly fail-closed improvement over the previous argv-exposed/silent-file-fallback behavior. Approved.