Forbid unsafe code in fasterhenry-cli; CI guard for crate roots

[loom-fleet-dispatch]

Closes #168

• Adds #![forbid(unsafe_code)] to fasterhenry-cli lib.rs, main.rs and build.rs.
• Adds a step to the clean-room CI job that fails if any crate root (lib.rs, main.rs, src/bin/*.rs, build.rs) lacks it.

Checked: guard script passes locally; cargo clippy -p fasterhenry-cli --all-targets clean.

🤖 Generated with Claude Code

[loom-fleet-dispatch]

Judge evaluation of head 0c926e9: no blocking findings from the four-file diff.

Verification:

• Ran the exact new CI shell block in the PR worktree: exit 0.
• Ran that block against temporary fixtures: all four guarded root types pass; removing the attribute from src/lib.rs, src/main.rs, src/bin/tool.rs, or build.rs individually produces exit 1 and the corresponding error.
• git rev-list --count HEAD..origin/main returned 0.
• check-review-feedback.sh returned CLEAR (0 formal reviews, 0 inline comments).
• Local Clippy could not run: Cargo is unavailable in this environment. The builder's Clippy result was not independently verified.
• No TDD declaration is present; advisory only.

loom-daemon forge wait-checks 170 --timeout 0 reports pending Rust checks on macOS, Ubuntu ARM, and Ubuntu x86 at this head. No verdict applied. Releasing loom:reviewing and keeping loom:review-requested so a later Judge pass can evaluate after CI settles.

[loom-fleet-dispatch]

Approved. #![forbid(unsafe_code)] is now at every workspace crate root (fasterhenry-cli lib.rs, main.rs, build.rs; the core crate already had it). The CI guard in the clean-room job greps every src/lib.rs, src/main.rs, src/bin/*.rs and build.rs, and fails with an annotation on any root that lacks the attribute. I ran the same loop locally and all four real roots pass. cargo check --workspace --all-targets is clean. All CI checks are green and the merge state is CLEAN.

Non-blocking note: a local find also picks up stale .loom/worktrees copies. This does not affect CI, but excluding .loom in the find would make the guard behave the same locally.

[loom-fleet-dispatch]

Standing down: the verdict-time label recheck found loom:pr already present on head 0c926e9, so another Judge completed approval during this review. My independent checks found no blocking issue: repository guard exit 0; missing-attribute fixture exit 1; corrected fixture exit 0; merge-tree exit 0; all seven GitHub checks pass; formal review gate CLEAR. Local Cargo checks could not run because cargo is unavailable. No verdict was posted by this session: post-verdict.sh refused because the installed loom-daemon lacks forge wait-checks (requires >=0.19.707). Preserving the existing verdict.

[loom-fleet-dispatch]

Verdict anchored to the current head — no marker had been recorded

This PR carries loom:pr, but no verdict-SHA marker was ever written for that verdict, so it was unverifiable: nothing could tell whether it still described the tree in front of it, and it would have survived a force-push undetected — the exact pre-#5686 hazard.

This comment records the head SHA as of now, 0c926e99bc992c5d496e59eb00695e7d3d3ba6e4. It is not a review and implies no judgment about this tree: the loom:pr label is unchanged. From here on the verdict is invalidatable — if the head moves off 0c926e99bc992c5d496e59eb00695e7d3d3ba6e4, the stale-verdict pass clears loom:pr and returns the PR to loom:review-requested.

Anchoring bounds future exposure; it cannot reconstruct which tree was actually reviewed. If the head already moved before this comment, treat the verdict with corresponding suspicion.

---

Automated by loom-daemon claim reconciliation (#6319)

[loom-fleet-dispatch]

Landing order recorded — this PR overlaps other open work

Planned by the merge-sequencing pass (#9686): this PR lands AFTER #161, because it changes files #161 also changes. Order within overlapping work is oldest-first; independent PRs are unaffected.

While the loom:sequenced label is present, merge-pr.sh refuses to merge this PR (the #9378 gate). The label clears mechanically when #161 lands at the recorded head — or by re-evaluation if it closes or moves. This is a scheduling preference: it suppresses only redundant base-conflict repairs while #161 is in flight, never a genuine review finding.

---

Automated by loom-daemon claim reconciliation (#9686, plan seq-f5504909)

[loom-fleet-dispatch]

Champion: Holding for Human Merge — Critical File

• Critical File Exclusion Check: .github/workflows/ci.yml matches critical-file pattern .github/workflows/. Current-head approval is fresh and all seven CI checks pass; these do not waive the critical-file exclusion.

This PR needs a human merge. Remove loom:operator and use ./.loom/scripts/merge-pr.sh 170 in either order. The release is respected while this change remains equivalent; Champion cannot auto-merge a critical-file change.

---

Automated by Champion role

loom dashboard