Upgrade smithers-orchestrator to smthrs

[Will Cory (roninjin10)]

The smithers-orchestrator npm package was renamed to smthrs as of 0.33.0, with no compatibility alias published under the old name. This PR migrates the pinned installer metadata from smithers-orchestrator@0.23.0 to smthrs@0.33.0.

Changes

• scripts/fleet/setup/external-tools.json: repository npm:smithers-orchestrator → npm:smthrs, version 0.23.0 → 0.33.0, refreshed SRI integrity, publish date, and soak-bypass window (published 2026-08-02, removable 2026-08-09), and updated notes/description.
• scripts/fleet/setup/lib/install-smithers.mjs: tarball URL now points at https://registry.npmjs.org/smthrs/-/smthrs-<version>.tgz; doc comment updated. The bin entry (src/bin/smithers.js) and shim name are unchanged and match the published package.

Verification

• git grep smithers-orchestrator is clean.
• npm confirms smthrs@0.33.0 is published (2026-08-02T06:14:17Z) with matching tarball URL, SRI integrity (sha512-X2KvPu3Ly5jt…), and bin path src/bin/smithers.js.
• No package.json dependency or lockfile referenced the package, so none needed updating.
• Independent reviewer pass: diff limited to the required rename/version migration; JSON integrity checks pass.

🤖 Generated with Claude Code

---

Note

Low Risk
Scoped to fleet bootstrap pin/install URLs and SRI metadata; no app auth, data paths, or lockfile dependency changes.

Overview
The upstream npm package smithers-orchestrator was renamed to smthrs (no alias on the old name), so fleet bootstrap metadata and the installer now pull smthrs@0.33.0 instead of smithers-orchestrator@0.23.0.

external-tools.json updates the smithers tool entry: repository, version, SRI integrity, notes/description, and a dated soakBypass for the fresh publish (2026-08-02, removable 2026-08-09). install-smithers.mjs points the registry tarball URL at smthrs; the smithers shim name and entry path src/bin/smithers.js stay the same.

^{Reviewed by Cursor Bugbot for commit 2cc4ea6. Configure here.}

[John-David Dalton (jdalton)]

Thanks for catching the rename and pinning it precisely — the diagnosis is right, and 0.33.0 with no compatibility alias is exactly the failure shape.

Both files here are generated: they arrive in this repo through our scaffolding sync, so a change landed in this copy gets overwritten the next time that sync runs. The fix has to go in at the source instead, and then it reaches every repo that uses the installer rather than just this one. I'm handling that side.

Two things I'll settle while doing it: the version needs to clear our 7-day install soak (0.33.0 published 2026-08-02, so it's eligible 2026-08-09), and I'll re-derive the integrity hash from the registry rather than copying it across — standard practice for us on any pinned artifact, nothing to do with this PR.

Closing this one since it can't land in a generated file, but the change ships from the source side. Appreciate the writeup.