Add build, package and release workflows

[janthoXO]

Closes #3. Finishes the open part of #1 and unblocks #21.

Workflows

Release calls Package, and Package calls Build, so nothing is duplicated.

Workflow	Runs on	Does
build.yml	every pull request	swift build, swift test, ray lint
package.yml	pull requests to main	Build, then in parallel: bundle.sh plus the zipped app as an artifact; install, test and audit the Homebrew formula from a local tap; ray build, which compiles the app into the extension
release.yml	every push to main	Determine the version, Package with it, create the GitHub release with the zip, point the formula at the new tag and commit it, publish the Raycast extension

For a macOS app, "package" is the equivalent of your Docker image build: Build only checks that the code compiles and passes tests, while Package checks that the three shipping artifacts can be produced — the signed .app, a working Homebrew formula and the Raycast extension bundle.

No duplicate runs

Every workflow triggers on all pull requests, and each also runs when its own workflow file or one it depends on changes. A first scope job then calls the new .github/actions/ci-scope, which reads the changed files and picks the outermost workflow that must run:

• release dependencies changed (release.yml, package.yml, build.yml, determine-version, ci-scope) → Release runs, as a dry run: it packages and prints what it would publish, but creates no release, commit or Store submission.
• else pull request targets main, or package.yml/build.yml/ci-scope changed → Package runs.
• else → Build runs.

The other two skip. A called workflow skips its own scope job, because github.workflow is then the caller's name.

Release details

• Version comes from your determine-version action. bundle.sh now writes $VERSION into the Info.plist when set, and the formula sets it from the tag for stable builds.
• GitHub release v<version> at the pushed commit, with KlangLadder-v<version>.zip and a Gatekeeper note.
• Homebrew: the job rewrites the formula's url to the new tag plus revision and commits it to main as github-actions[bot]. Pushes made with GITHUB_TOKEN don't trigger workflows, so this doesn't loop. If you protect main later, the bot needs an exception.
• Raycast: before building, the job swaps the ../.. path dependency for the GitHub URL at the new version, since the Store builds the extension outside this repo. ray publish needs two secrets, RAYCAST_TOKEN and RAYCAST_GITHUB_TOKEN. Without them the step logs a warning and skips.

Tested

• actionlint passes.
• The formula rewrite script and VERSION=… ./bundle.sh were run locally: the version lands in the Info.plist, the signature still verifies, and rewriting the formula twice in a row is idempotent.
• The workflows themselves only really run once this is on GitHub. The first pull request run will show whether the scope gating behaves as intended.

Notes

• README documents the release download; README_DEV has a CI section.
• ray publish in CI is untested and needs Publish the Raycast extension to the Raycast Store #21 first (a Store username and a LICENSE file).
• Runners use macos-latest. If its Xcode drops below 16.3, the Raycast build breaks.

[janthoXO]

Changed as requested:

• Release no longer runs on pull requests. It only runs on pushes to main. To check the release path without publishing, run it manually from the Actions tab and leave the new publish input off: it packages everything and prints what it would publish, but creates no release, no formula commit and no Store submission.
• Package only runs on pull requests to main (pull_request: branches: [main]).
• Build runs on pull requests to every other branch (branches-ignore: [main]), because on pull requests to main it runs inside Package.

That makes the triggers non-overlapping on their own, so the ci-scope action and the scope jobs are gone. The trade-off: a pull request that only changes release.yml is no longer exercised by CI, which is what the manual run is for.

README_DEV updated to match.