ho-04.12 — run signal semantics & Keychain modernization

Fifth post-sweep hardening ho (fable sweep, 2026-07-03; Tier B candidates #2 and #7), plus the vault-scaffold defect found in the 2026-07-03 signed-install smoke. The theme is what happens when the world interrupts sharibako: a signal arrives mid-operation, the Keychain API ages out from under the provider, a vault arrives from a git clone without the directory a verb assumes.

This ho is dogfood-gated. Two of its changes cannot be verified by the test suite: Ctrl-C behavior against a real child process on a real terminal, and Keychain itemExists semantics under the signed entitlement. Both get verified on the signed install (scripts/install.sh) before this ho closes. The suite covers everything else through injectable seams.

In scope:

• Signal hygiene for the plaintext age-key temp file (the security payload).
• run's signal forwarding semantics: double-SIGINT, escalation, SIGQUIT, PID reuse.
• KeychainAgeKeyProvider.itemExists off the deprecated API; OSStatus branching at the provider.
• -Xswiftc -warnings-as-errors in CI and pre-commit, sequenced after the deprecation clears.
• findExecutable honoring PATH (both Shell copies).
• Vault scaffold creation on the write path (shared/ missing in a fresh or cloned vault).

Out of scope:

• Non-atomic ingest — the 2026-07-03 smoke's second finding (a failed mid-ingest apply leaves a zombie scope in the vault, no marker in the project, and retry de-collides to a new scope ID instead of reconciling). Its fix needs a recovery-semantics decision that doesn't belong in a hardening cluster; it becomes its own candidate ho.
• Deferred decision: add loads the identity it doesn't need. ho-04-cli.md:116 planned add as a no-private-key verb — encryption needs only the recipient — but shipped AddCommand loads the identity, so Touch ID fires on a verb that could run without it. Flagged by the sweep for "whichever ho opens next" and not yet named by 04.10, 04.11, or this ho's ratified slate. Pull it in if execution finds it adjacent to the D5 provider work; otherwise it stays a named deferral for a future ho.
• Config layer — Tier B #10, waits for ho-05.

Phase 1 — Think

Eight decisions, ratified in session (2026-07-06, following a code scout of SignalForwarder, KeychainAgeKeyProvider, and both Shell copies).

Decision 1 — temp-key signal hygiene (cleanup-then-reraise). KeychainAgeKeyProvider writes the decrypted age key to $TMPDIR/sharibako-key-<uuid> (0600) and scrubs it only on normal return — any fatal signal in that window leaks the plaintext key to disk, disclosed in SECURITY.md's Known Limits since the sweep. New behavior: for the life of the temp file, SIGINT/SIGTERM/SIGHUP/SIGQUIT are trapped by a handler that scrubs and deletes the file, restores the default disposition, and re-raises — the process still dies of the same signal, observably, after the key is gone. The prior art (InteractiveSelect._sigintRestoreAndReraise) was deleted with its widget in ho-04.11; this is written fresh, with the handler seam injectable so tests can drive it without signaling the test runner.

Decision 2 — stop forwarding SIGINT; keep the countdown. run's child shares sharibako's process group, so a terminal Ctrl-C is delivered to the child by the kernel already; SignalForwarder then forwards a second SIGINT, and npm-class tools treat the second as hard-abort. Rather than move the child to its own process group (which buys foreground/job-control complexity a secrets wrapper has no business owning), the forwarder stops forwarding SIGINT and only starts the escalation countdown — the child already has the signal. SIGTERM and SIGHUP keep forwarding (they target the wrapper alone), and SIGQUIT joins the forwarded set. Known cost, accepted: a targeted kill -INT <wrapper-pid> no longer reaches the child; SIGTERM is the targeted-shutdown path.

Decision 3 — repeated signal escalates instead of resetting. startCountdown() currently cancels and restarts the one-second SIGKILL countdown on every signal — mashing Ctrl-C postpones SIGKILL indefinitely, the inverse of what mashing means. New behavior: a signal arriving while a countdown is active sends SIGKILL immediately.

Decision 4 — liveness through the Process object. kill(childPID, 0) probes and kill(childPID, SIGKILL) fires against a raw PID that the kernel may have recycled between grace expiry and delivery. Both go through the Process reference (isRunning, terminate/interrupt where they fit, raw kill only guarded by isRunning), which cannot alias a recycled PID.

Decision 5 — Keychain itemExists off the deprecated API. kSecUseAuthenticationUI: kSecUseAuthenticationUIFail (deprecated since macOS 11) is replaced with kSecUseAuthenticationContext carrying an LAContext with interactionNotAllowed = true; SecItemCopyMatching statuses are branched at the provider (errSecSuccess and errSecInteractionNotAllowed mean present; errSecItemNotFound means absent; anything else surfaces as an error rather than a silent false). Dogfood gate: on the signed install, itemExists must still detect the item without firing Touch ID.

Decision 6 — findExecutable honors PATH, fixed dirs become the fallback. Both Shell (core) and CLIShell probe four hardcoded directories while the error text and CLAUDE.md say "on PATH" — the code and the contract disagree. Ratified: search PATH first, then the existing fixed list (which is what keeps GUI-launched contexts working, where PATH is minimal). The threat-model call — a poisoned PATH could serve a hostile age, but anyone who can edit PATH can alias sharibako itself — gets one honest sentence in SECURITY.md. The duplicated search logic stays duplicated for now; the two copies exist because Shell is internal to the core (noted in CLIShell's header), and unifying them is not this ho's business.

Decision 7 — -warnings-as-errors, sequenced after Decision 5. With the deprecation cleared, CI's build/test invocations and the pre-commit swift build hook gain -Xswiftc -warnings-as-errors, per languages-swift.md. Sequencing matters: adding the flag first would redden CI on the warning Decision 5 exists to remove.

Decision 8 — vault scaffold ensured at the write choke point. VaultLayout.createVaultLayout(at:) is called only from test fixtures — no production path ever creates shared/, and scopes/ exists only by the accident of createScope's withIntermediateDirectories: true. The first promote-to-shared in a fresh vault dies with a raw age "failed to write header" error (2026-07-03 smoke, reproduced). A vault synced by git has the same hole: git doesn't track empty directories, so a clone with no shared entries arrives without shared/. Fix at the choke point: encryptAndWrite ensures the destination's parent directory before invoking age, covering addSharedEntry, every scope write, and any future writer. createVaultLayout remains for fixtures; the fixture convenience is why the suite never saw the bug, and the new test runs against a deliberately unscaffolded vault.