consumer adoption: fbuild — 4.1.0 upgrade + broker client decision

[zackees]

Part of #354 (consumer adoption). Work happens in zackees/fbuild; tracked here.

Scope

• Upgrade running-process 4.0.0 → 4.1.0 (fbuild uses default-features = false, core spawn API only — Job Objects/pgid containment).
• Decide and document whether fbuild's daemon should adopt the broker client (connect_to_backend) or remain core-only: fbuild's workspace comment says client/daemon features are deliberately unused. If adoption is in scope, wire it + .servicedef; if not, record the decision here and in the fbuild workspace docs so meta: track deferred running-process v1 broker completion work after #228 #354 has no untracked deferral.
• Cut an fbuild release with the dep upgrade.

Acceptance

• 4.1.0 upgrade merged
• Broker adoption either wired or explicitly declined with rationale
• fbuild release published

[zackees]

Research findings + plan

Does fbuild-daemon have clients that discover/connect to it? Yes — but over localhost HTTP, not local-socket IPC:

• Daemon: axum HTTP server binding 0.0.0.0:<port> (default 8765 prod / 8865 dev), crates/fbuild-daemon/src/main.rs:135-163; writes pid + port files and serves /health.
• Discovery: fbuild_paths::get_daemon_port_file() / get_daemon_port() + http://127.0.0.1:<port> base URL (crates/fbuild-paths/src/...:45,199-231).
• Client: crates/fbuild-cli/src/daemon_client.rs (reqwest) — health() / health_full() (line ~428-447) returns pid + source_mtime for stale-daemon detection; ensure_daemon_running() (line 813) spawns the daemon if absent. Stale-PID-file handling exists before bind (main.rs:136-150).

Recommendation: decline broker adoption (core-only is correct).
Rationale with evidence:

1. Transport mismatch — BackendHandle::probe/connect (running-process src/broker/backend_handle.rs:102,311) operate on broker Endpoints (local socket / named pipe via interprocess). fbuild's daemon speaks HTTP over TCP; soldr-style header-peek multiplexing of the nonce probe is not feasible inside axum without a second raw listener.
2. Equivalent guarantees already exist — /health returns pid + source_mtime, giving liveness + staleness checks the BackendHandle probe would otherwise provide; the CLI already self-heals via ensure_daemon_running().
3. The workspace comment (Cargo.toml, running-process = { version = "4.0.0", default-features = false } block) already records client/daemon features as deliberately unused — this decision just needs to be made explicit and current.

Plan:

1. Bump running-process 4.0.0 → 4.1.0 in workspace Cargo.toml (keep default-features = false). Call sites unchanged: crates/fbuild-core/src/containment.rs:59 (ContainedProcessGroup, ORIGINATOR_ENV_VAR) and crates/fbuild-core/src/subprocess.rs. 4.1.0 is on crates.io; expect a lockfile-only diff plus any transitive bumps.
2. Document the decline: extend the workspace Cargo.toml comment to state the broker-client decision and link this issue; add a short "Why not the running-process broker" note to crates/fbuild-daemon/README.md (HTTP transport rationale above). No .servicedef — the broker never launches fbuild-daemon.
3. Evidence/test plan: full fbuild suite incl. crates/fbuild-daemon/tests/process_containment.rs and port_recovery.rs (containment is the only contract consumed); verify cargo tree -i running-process shows core-only feature set.
4. Cut an fbuild release (workspace version bump per fbuild's release process) and tick the acceptance boxes here, linking back to meta: track deferred running-process v1 broker completion work after #228 #354.

Risks: low — dep bump only. Watch for any 4.1.0 core-API signature changes at the two call sites (none expected; 4.x line). Revisit adoption only if fbuild ever moves daemon RPC off HTTP or wants broker-managed lifecycle.

[zackees]

Staged locally (push hold still in effect): zackees/fbuild branch chore/running-process-4.1.0 (worktree .claude/worktrees/issue-rp-384, commit 38666a93).

• running-process 4.0.0 → 4.1.0 in workspace Cargo.toml, default-features = false retained; lockfile re-resolved from crates.io
• Broker decline documented in the manifest comment + new "Why not the running-process broker" section in crates/fbuild-daemon/README.md (HTTP-over-TCP transport mismatch, /health equivalence)
• Verified: cargo check --workspace clean; ignored containment contract test daemon_children_die_when_daemon_dies passes on 4.1.0; cargo tree -i running-process confirms core-only feature set

Remaining when the hold lifts: push branch, PR, merge, fbuild release (version bump per fbuild release process), tick acceptance boxes.

[zackees]

Landing update (2026-06-12):

• 4.1.0 upgrade merged — chore(deps): bump running-process to 4.1.0 FastLED/fbuild#534 (core feature only, default-features = false, unchanged).
• Broker adoption explicitly declined with rationale — documented in crates/fbuild-daemon/README.md ("Why not the running-process broker"): transport mismatch (broker routes over local sockets/named pipes vs fbuild's loopback-HTTP axum daemon), equivalent liveness/stale-detection guarantees already via GET /health + ensure_daemon_running(). Revisit only if daemon RPC moves off HTTP.
• fbuild release — not yet cut; feat(broker-v2): single-instance enforcement diagnostic + EX_TEMPFAIL exit (slice 2 of #532) #534 was a dep-bump without a version bump, so no release workflow triggered. Needs a version bump to publish.

[zackees]

Final acceptance item complete:

• fbuild release published — chore(release): bump version 2.2.25 -> 2.2.26 FastLED/fbuild#535 (version 2.2.25 → 2.2.26) merged; Autonomous Release run 27437145907 completed successfully; release v2.2.26 is live (2026-06-12T19:19:49Z), carrying the running-process 4.1.0 upgrade.

All three acceptance criteria are now met (4.1.0 merged in #534, broker adoption explicitly declined with rationale in crates/fbuild-daemon/README.md, release published). Closing.