feat: installable protostar CLI (PROT-6)

[BlakeHastings]

Summary

Lands the first protostar component — an installable CLI (Jira PROT-6) — and the versioning + release automation that ships it. After this merges, releasing is "merge a Release PR"; the version flows from a git tag into the binary with no manual edits.

This PR bundles two logically distinct parts; they are described separately below.

---

Part 1 — The protostar CLI (PROT-6)

A self-contained, single-file binary (no .NET runtime required on the target machine), built on Spectre.Console.Cli.

• Commands: default banner/status command, plus protostar install and protostar uninstall — the binary installs itself into a per-user directory and manages PATH.
  • src/Protostar.Cli/Commands/{DefaultCommand,InstallCommand,UninstallCommand}.cs
  • src/Protostar.Cli/Install/InstallEnvironment.cs
• Curl-able installers that download the right release asset and run protostar install:
  • scripts/install.ps1 (Windows), scripts/install.sh (Linux/macOS)
• Project: src/Protostar.Cli/Protostar.Cli.csproj (net10.0, AssemblyName=protostar), Program.cs, .gitattributes.

Part 2 — Versioning + automated releases

• Version from git tags (MinVer). Directory.Build.props adds MinVer (build-time only). The version is no longer hardcoded — CliInfo.cs now reads AssemblyInformationalVersionAttribute at runtime (trim/AOT-safe) and strips the +<sha> metadata. This removes the old const Version = "0.1.0" and its duplication in the README.
• Releases via release-please. .github/workflows/release-please.yml plus release-please-config.json, .release-please-manifest.json, and version.txt. release-please maintains a Release PR (version + changelog) from Conventional Commits; merging it tags main, creates the GitHub Release, and a build job attaches binaries for win-x64, win-arm64, linux-x64, osx-arm64.
• README gains a "Releasing" section documenting the flow.

Design decisions worth a reviewer's eye

• release-please and MinVer compose: release-please decides the version and creates the tag on main; MinVer reads that tag at build time and stamps the binary. One source of truth (the tag).
• Tag format is deliberate: include-component-in-tag: false makes tags v0.1.0 (not protostar-v0.1.0) so MinVer's v prefix matches. This is load-bearing.
• No PAT needed: the build job runs in the same workflow run as release-please (gated on release_created), so the "GITHUB_TOKEN does not trigger downstream workflows" limitation does not apply.
• Release assets are raw binaries named protostar-<rid>[.exe], matching exactly what scripts/install.* fetch from releases/latest/download/.

What this changes about our workflow (after merge)

• Give PRs Conventional Commit titles (feat:, fix:, feat!: for breaking) and squash-merge — the squash subject is what release-please reads.
• To ship: merge the Release PR release-please opens. No manual tagging, ever.
• First release: this feat: PR takes the baseline 0.0.0 to 0.1.0, which release-please will propose in the first Release PR.

Verify locally

dotnet build -c Release
dotnet run --project src/Protostar.Cli -- --version   # untagged -> pre-release e.g. 0.1.0-alpha.0.N
dotnet run --project src/Protostar.Cli                # banner: protostar v<version>

Tagging a commit v0.1.0 and rebuilding makes --version report a clean 0.1.0 (verified locally), which is exactly what release-please will produce on main.

🤖 Generated with Claude Code