feat(ci): add cached setup-wright Action

[e54-bot]

Refs wrightkit/setup-wright#3

Summary

• Adds the composite Action .github/actions/setup-wright (version: exact or latest, cache: on/off) plus one helper script. It installs Wright from the existing R2 release contract (latest/version, versioned archive, .sha256) and puts wright on PATH.
• Caches only the executable and a SHA-256 sidecar via actions/cache restore/save (SHA-pinned), with the exact key setup-wright-v1-<version>-<target>. No restore prefix.
• Docs: docs/setup-wright-action.md (usage, pinning, cache identity, scope), linked from the README and docs/README.md.
• CI: new setup-wright Action job (path-filtered, wired into CI result).

Contract check

The release contract already publishes everything needed: wright/latest/version, immutable wright/releases/<version>/ archives and .sha256 files (docs/release.md, v0.28.0 live). No distribution change.

Verification

• scripts/test-setup-wright.sh: 22 cases pass locally (hit with zero requests, miss, latest resolution and new-version key, OS/arch/version key separation, corrupt/missing-sidecar/wrong-version cache, checksum mismatch, missing release, unsupported platforms, PATH).
• actionlint passes on the workflows; shellcheck is clean on the Action script.
• Ran resolve/install/verify-cache against the live release on macOS arm64: v0.28.0 downloaded, verified, then wright check passed with a PASS step summary.

Not verified

• The Action running inside GitHub Actions (restore/save through the real cache service, Linux/Windows runners): the new CI job does this on this PR and must be green.
• Consumption from a Wright release ref (@vX.Y.Z) cannot run until a release contains the Action.
• Untrusted-PR cache isolation relies on GitHub's cache scoping; it is documented, not exercised.
• Windows (.zip) was not run locally.

Hence Refs, not Fixes.

[Teakowa]

Approve (round 1), with non-blocking notes. Refs #717 is correct.

Verified by me

• Local tests: scripts/test-setup-wright.sh passes 22/22. I mutated it twice. Dropping the sidecar SHA comparison in verify-cache fails "corrupt cached executable is rejected". Neutering the download checksum check fails "checksum mismatch fails". The tests catch both.
• Lint: actionlint on ci.yml is clean. shellcheck reports only an SC2015 info note in the test script.
• Cache key: the exact key setup-wright-v1-<version>-<target> is used in both restore and save, with no restore-keys. Unsupported OS/arch pairs (for example Linux ARM64) fail in resolve.
• Order of checks: the SHA-256 is verified before extraction, and the executable is copied to the cache dir and saved only after that. A failed --version check removes the dir, so a failed install is not saved.
• Safety: workflow permissions is contents: read, with no secrets. inputs.version reaches the shell only through env, and the semver regex gates what is written to GITHUB_OUTPUT. The actions/cache pin 55cc834… matches tag v6.1.0.
• CI: the three setup-wright Action jobs (ubuntu, macOS, Windows) passed. Rust (stable) / Quality, Product integration and Build dist (macos-15) were still pending at review time.
• Acceptance criteria: the PR body marks what is not verified. Untrusted-PR isolation relies on GitHub cache scoping and is documented, not exercised. Consuming from a release ref is impossible until a release contains the Action.

Non-blocking notes

1. setup-wright.sh (verify-cache and install): wright --version | grep -Fq "$version" is a substring match. echo 'wright 0.28.10' | grep -Fq 0.28.1 matches. The sidecar hash makes accidental reuse unlikely, but the check is weaker than the wrong-version criterion. Anchor it, for example grep -Eq "(^|[^0-9.])${version//./\\.}([^0-9.]|$)", and add a test.
2. An invalid cache entry keeps its key, so every later run downloads again until eviction. This is documented. Consider a follow-up that includes a content discriminator in the key.
3. The sidecar detects corruption, not a malicious writer who can alter both files. This is stated in the docs, which is the right boundary for this scope.
4. The CI smoke depends on the live latest release and network. A release in flight can fail an unrelated PR.
5. Unit tests do not run on Windows, so the Windows .zip path is covered only by the live smoke job.

Not found: the task named docs/mechanical-guards.md and docs/release-engineering.md. Neither exists on this branch, so I could not check against them.

[e54-bot]

Superseded: the setup-wright Action moved to its own repository, wrightkit/setup-wright (PR #1 there, merged). The implementation, tests and review history carried over.