docs: align attestation verification example with downloaded binary names

[dyoshikawa]

Background

PR #2352 adds GitHub Artifact Attestation verification to the installation guide. The surrounding manual-install instructions rename each downloaded release binary to a platform-neutral local filename.

Details

The new verification example uses rulesync-darwin-arm64, but the preceding macOS installation steps save the file as rulesync; Windows saves it as rulesync.exe. Following the guide verbatim therefore makes gh attestation verify target a file that does not exist. The same mismatch is present in the synchronized skill documentation.

Solution / Next Steps

Use the actual local filenames in the example, or use a clear placeholder such as <downloaded-binary-path> with platform-specific examples. Update both the installation guide and synchronized skill documentation, then validate the rendered instructions.

Found during review of #2352.

[dyoshikawa]

Heads-up from triaging #2352: the section this issue is about never actually landed.

main has the CI half — publish-assets.yml carries artifact-metadata: write, attestations: write and id-token: write, and runs actions/attest@v4.2.0 against dist-bun/SHA256SUMS. But docs/getting-started/installation.md and skills/rulesync/installation.md have no "Verify build provenance" section at all; #2352 is the only place that text ever existed, and I'm closing that PR as superseded on the CI side.

So this is now "add the section, with the filename mismatch already fixed" rather than "correct an existing example". The wording to start from is in #2352's diff — just don't carry over the rulesync-darwin-arm64 example, since the surrounding steps save the binary as rulesync (or rulesync.exe on Windows).

[dyoshikawa]

Processed in the 2026-07-29 scrap-issue batch. Fixed by #2473.

Taking the maintainer note above: the section never landed, so this adds it rather than correcting an existing example. The verification command targets the path the preceding manual steps actually install to — /usr/local/bin/rulesync on Linux/macOS and C:\Windows\System32\rulesync.exe on Windows — instead of the release asset name.

Three things turned up while checking the text against reality, worth recording:

• The rename is genuinely harmless, and the docs now say why. gh attestation verify looks the artifact up by content digest, not by name. Confirmed against the real release: the SHA-256 of rulesync-linux-x64 from v16.0.0, downloaded as ./rulesync, resolves to a https://slsa.dev/provenance/v1 attestation whose subjects are all five binaries, built by .github/workflows/publish-assets.yml in this repository.
• --repo alone does not prove which workflow signed it — it only checks repository identity, as gh's own help notes. The example pins --signer-workflow dyoshikawa/rulesync/.github/workflows/publish-assets.yml, which matches the signing certificate's SAN, so the sentence about "built by this repository's release workflow" is actually true of the command shown. The section also states the v2.49.0 minimum (where gh attestation was introduced) and that the CLI must be signed in, since verification hits the API even for a public repository.
• The npm package does carry provenance, contrary to a first assumption during review: registry.npmjs.org/rulesync/latest reports dist.attestations.provenance.predicateType: https://slsa.dev/provenance/v1. The docs point npm users at npm audit signatures rather than claiming the package is unattested.

No workflow changes were needed — the CI half was already on main, as noted.