Harden macOS triad startup and degraded VFS workflows

[GavinPacini]

Summary

• harden macOS enrollment directory ownership and activation readiness handling
• keep wallet projection refresh out of short-lived daemon construction while making /next.md explicitly live-first with degraded cached behavior
• let the triad developer launcher run without an NFS 4.1 mount and direct developers to authenticated bloom vfs commands
• add a foreground --services-only launcher mode so Session Sentinel, Signer, and Broker stay alive while developers rebuild and restart Machine independently
• export the selected debug Machine build on PATH through triad.env, with deterministic owned-service teardown on Ctrl-C or terminal closure

Why

Local canary testing exposed two startup problems: enrollment generation rejected installer-created output directories with the wrong ownership boundary, and activation could perform its readiness check before Broker had published its socket. Separately, short-lived VFS commands triggered an untracked Broker projection refresh, and macOS versions without NFS 4.1 support could not use the generic triad developer harness at all.

Once the harness could run without a mount, Machine development still required restarting the whole triad for every rebuild. The new services-only mode keeps the stateful Broker and Signer processes stable in one foreground launcher while Machine remains fully developer-owned in another terminal.

This keeps production startup fail-closed where required, preserves degraded Broker-independent VFS operation, provides a supported IPC/VFS-only development path when kernel mounting is unavailable, and shortens Machine iteration without weakening service isolation. Explicitly requested mounts remain strict and fail with an actionable fallback message.

Services-only workflow

Start the dependencies in one terminal:

scripts/triad-dev-launch.sh \
  --services-only \
  --developer-root ~/.bloom/triad-dev \
  --machine-home ~/.bloom/triad-dev/machine-home \
  --machine-socket /tmp/bloom-triad-machine.sock \
  --log-dir /tmp/bloom-triad-logs \
  --ready-file /tmp/bloom-triad-ready

Then iterate on Machine in another terminal:

source /tmp/bloom-triad-logs/triad.env
cargo build -p bloom --no-default-features --features mount,triad-dev-harness && \
  bloom serve --endpoint "$BLOOM_RPC_ENDPOINT"

Validation

• cargo fmt --check
• bash -n scripts/triad-dev-launch.sh
• cargo test -p bloom-vfs — 344 tests passed before the latest target update; after rebasing onto 7bb1450, 335 unit tests pass and one upstream test fails because deddd48 changed single-payload Petal claims to the canonical batch digest without updating this VFS fixture
• cargo test -p bloom-daemon — 50 tests passed before the latest target update; after rebasing onto 7bb1450, 46 unit tests pass and one upstream production-path test fails with the same deddd48 payload-digest mismatch
• cargo test -p bloom-it --test triad_release — 32 tests passed before the latest target update
• post-rebase cargo test -p bloom-it --test triad_release triad_developer_launcher_ — 6 tests passed
• cargo build -p bloom --no-default-features --features mount,triad-dev-harness
• live no-mount triad smoke test with bloom vfs ls / and bloom vfs cat /next.md
• live services-only smoke test verified all three owned service sockets, debug bloom PATH resolution, absence of a launcher-owned Machine socket, and cleanup of runtime/readiness state on Ctrl-C

Checklist

• Tests added or updated for behavior changes
• Architecture docs (docs/architecture/) updated if contracts or behavior changed — N/A: this PR changes startup lifecycle and developer tooling, not a published architecture contract; lifecycle design notes and local integration documentation are included in the PR
• Sealed Approval invariants respected (no signing outside a grant or bounded capability, no PRF/grant persistence, execution from sealed bytes) — N/A: this PR does not change signing, grant, capability, or sealed-byte execution paths
• Agent Documentation updated (crates/bloom-vfs/src/docs/agent-guidance.md and affected Petal READMEs) — N/A: no agent-guidance or Petal interface changes; the affected developer workflow is documented in docs/local-mainnet-integration.md