Add first-class installation and package-manager distribution

[Teakowa]

Goal

Make Wright straightforward to install for end users and automation without requiring them to understand target triples, manually download archives/checksums, extract binaries, or manage PATH by hand.

Provide a first-class installation layer over the existing GitHub Release artifact contract, with simple platform-native entry points for macOS, Linux, and Windows.

Context

#101 established and shipped Wright's versioned binary release contract. v0.1.0 now publishes deterministic standalone archives and checksums for:

• Linux x86_64;
• macOS arm64;
• macOS x86_64;
• Windows x86_64.

The current README installation flow is intentionally low-level: users select a target triple, download the archive and checksum, verify it, extract it, and update PATH. That remains useful as a fallback and as the underlying distribution contract, but it is too cumbersome to be the primary user-facing installation experience.

This issue should add an installation/distribution frontend without introducing a second binary build path.

Distribution contract

GitHub Release artifacts remain the canonical shipped binaries.

All installers and package-manager manifests introduced here must consume the release artifacts produced by Wright's existing release workflow rather than independently rebuilding Wright.

This keeps installation channels aligned with the same versioning, checksums, smoke tests, and standalone-runtime guarantees already established by #101 and docs/release.md.

Scope

Unix install script

Add a supported install.sh path for Linux and macOS that:

• detects supported OS and CPU architecture;
• resolves the corresponding Wright release artifact;
• installs the latest stable release by default;
• supports pinning an explicit Wright version for CI/agent workflows;
• downloads and verifies the published SHA-256 checksum before installation;
• installs both wright and wright-lsp;
• supports an explicit/custom installation directory;
• avoids requiring root for the default user-local installation path;
• reports actionable errors for unsupported platforms, missing dependencies, checksum failures, and permission problems;
• performs a minimal post-install version/smoke check.

The script should remain a thin release-artifact installer, not a general package manager or source-build frontend.

macOS / Homebrew

Provide a WrightKit-owned Homebrew distribution path, expected to use a dedicated tap such as wrightkit/homebrew-tap unless implementation evidence justifies a different repository layout.

Target user experience:

brew install wrightkit/tap/wright

The formula should consume the published macOS release archives and their checksums for both Apple Silicon and Intel rather than compiling Wright independently.

Windows / WinGet

Provide a WinGet package for the standalone Windows x86_64 distribution, targeting a simple portable CLI installation such as:

winget install WrightKit.Wright

Use the existing Windows release ZIP as the canonical payload where supported by the WinGet packaging model.

Document the external review/publication boundary of the community WinGet repository so Wright's release pipeline does not assume package availability is instantaneous.

Windows / Scoop fallback

Evaluate and, if low-maintenance, provide a WrightKit-owned Scoop bucket as a fallback/alternative Windows installation channel.

If implemented, it should also consume the canonical GitHub Release ZIP and checksum rather than rebuilding Wright.

Release integration

Extend release/distribution automation only as far as needed to keep supported installer metadata synchronized with new Wright versions.

Prefer generated or mechanically updated package metadata when practical, but do not build a large custom package-publication framework before there is evidence it is needed.

A temporary/manual publication step is acceptable for channels whose upstream repositories require review, provided the process is documented and version drift is detectable.

Documentation

Update user-facing installation documentation so the primary paths are concise and platform-oriented:

• macOS: Homebrew as the recommended path, install.sh as an alternative;
• Linux: install.sh as the recommended path;
• Windows: WinGet as the recommended path, with Scoop/manual ZIP as appropriate alternatives;
• CI/agents: deterministic version-pinned install.sh or direct release artifact consumption.

Keep manual GitHub Release installation and building from source available as fallback/advanced paths rather than the default quick-install experience.

Update docs/release.md so package-manager distribution is no longer described entirely as deferred once the corresponding channels are actually supported.

Non-goals

This issue does not require:

• Debian/Ubuntu APT repositories or .deb packages;
• Fedora/RHEL RPM/DNF repositories or .rpm packages;
• Arch/AUR packaging;
• Snap or Flatpak;
• MSI/MSIX installers;
• automatic self-update logic inside wright;
• crates.io publication;
• npm wrappers;
• macOS application bundles;
• code signing/notarization beyond what a selected distribution channel concretely requires;
• changing Wright's compiler/runtime architecture.

Additional Linux-native package formats should be added later only when real user/distribution evidence justifies their maintenance cost.

Deliverables

• Supported install.sh for Linux/macOS.
• Homebrew distribution for supported macOS architectures.
• WinGet manifest/package for Windows x86_64.
• Scoop support if the evaluation confirms it remains low-maintenance and useful.
• Release/update workflow or documented publication process for keeping package metadata aligned with Wright releases.
• README installation section reworked around one-command/platform-native installation.
• docs/release.md updated with the supported installation/distribution contract.
• Tests or CI validation sufficient to catch installer/platform mapping, checksum, archive-layout, and version-drift regressions.

Acceptance criteria

• A new macOS user can install the current stable Wright release with one Homebrew command and receive working wright and wright-lsp binaries.
• A new Linux user on a declared supported target can install Wright through one install.sh invocation without manually choosing a target triple or unpacking an archive.
• A Windows x86_64 user has a documented package-manager installation path centered on WinGet.
• CI/agent consumers can request an exact Wright version non-interactively.
• Every supported installation path ultimately installs binaries from the canonical GitHub Release artifacts rather than rebuilding independently.
• Published checksums are verified wherever the distribution mechanism permits Wright to control verification directly.
• Installer/package metadata version drift is detectable by CI or release validation.
• Unsupported OS/architecture combinations fail explicitly rather than selecting a potentially incompatible artifact.
• README's primary installation instructions no longer require manual target-triple/archive handling.
• Existing manual release downloads remain documented as a reliable fallback.

Dependencies / relationships

• Builds on completed Establish automated binary releases and the Wright v0.1 distribution contract #101, which owns the canonical versioned binary release contract.
• Complements the release/distribution contract in docs/release.md; it should not replace or duplicate the existing release build pipeline.
• This is a horizontal product/distribution workstream and should not absorb compiler compatibility, lint/analyzer, or language-frontend scope.

Planning notes

Prefer the smallest sustainable distribution surface:

GitHub Release artifacts
        |
        +-- install.sh
        +-- Homebrew
        +-- WinGet
        +-- Scoop (if justified)

Package-manager support should improve installation UX while preserving one authoritative binary provenance and release path.