…tation

Aligns boxlite's release artifacts with the 2026 cargo-dist / uv / ripgrep
convention. Per-file `.sha256` sidecars are what `cargo-binstall` and most
shell-based installers look for by default, and GitHub Artifact Attestations
(`actions/attest-build-provenance@v2`, OIDC-signed, no secrets) give users a
provenance check via `gh attestation verify` without us having to manage GPG
keys. The combined `SHA256SUMS` stays for batch verification.

README adds a short verification snippet pointing at the new sidecar and
attestation.

Adversarial review (Codex) flagged: when softprops/action-gh-release@v2
creates a release using GITHUB_TOKEN, the resulting release.published event
does NOT trigger downstream workflows. This is GitHub's anti-recursion guard,
confirmed in both softprops' README and GitHub Actions docs. The push.tags
trigger added in d9a0625 therefore silently broke fan-out to build-wheels,
build-node, build-c, and build-go — a tag would publish a release with the
CLI/runtime but no Python wheels, npm packages, or C archives.

Revert to release.published-only gating. The two-command release flow still
works fine:

    git push origin v0.9.4
    gh release create v0.9.4 --generate-notes --verify-tag

(The user's own token, not GITHUB_TOKEN, creates that release event, so all
SDK workflows fan out correctly.)

Adds `scripts/install.sh.template`, a POSIX-sh installer modeled after mise
and uv. CI substitutes `__VERSION__` and per-target `__SHA_*__` placeholders
from the just-generated `.sha256` sidecars and uploads the rendered
`install.sh` to the release. Users get:

    curl -fsSL https://github.com/boxlite-ai/boxlite/releases/latest/download/install.sh | sh

The script auto-detects target via uname, defaults to `$HOME/.local/bin`
(overridable with `BOXLITE_INSTALL_DIR`), verifies the tarball against the
embedded checksum on the fast path or fetches the `.sha256` sidecar for
non-current versions (`BOXLITE_VERSION=v...`), and atomically moves the
binary into place. Rejects macOS Intel and unsupported archs with a clear
error.

README's install block becomes a one-liner; the manual verify recipe
(sha256sum + gh attestation verify) stays underneath.

`scripts/release/install.sh.template` reflects what the file actually is:
release-time infrastructure consumed only by CI, not a script users run from
the repo. Matches the existing scripts/{build,ci,deploy,setup,images}/
subdir-by-purpose layout and leaves room for future release-side tooling
(release-note generator, version bumpers) alongside it.

…r pipe

Two Codex adversarial review findings:

1. The installer extracted with default tar settings and then `mv`'d the
   binary into place. When run with sudo for /usr/local/bin, tar's
   ownership-restore can plant a /usr/local/bin/boxlite owned by the CI
   runner's UID (501 on macOS runners, 1001 on Ubuntu) — which on many
   Linux desktops happens to be the user's own UID, making a privileged
   PATH binary writable by an unprivileged process. starship's installer
   has the same bug; uv and mise dodge it by never recommending the root
   path. We can do better with one line. Switched to
   `tar --no-same-owner` + `install -m 0755`, both portable across macOS
   BSD tools and GNU coreutils.

2. README's "pin a version" snippet placed BOXLITE_VERSION/INSTALL_DIR
   before `curl`. POSIX rule: `VAR=val cmd1 | cmd2` decorates only cmd1,
   so the variables never reached the `sh` process actually running the
   installer. Moved the env-var prefix to the sh side of the pipe.