ci: attach .tgz to GitHub Release on npm publish

[chailandau]

What

When the Changesets "version packages" PR (e.g. #148) is merged to main, release.yml already publishes @anarchitecture/ghost to npm and Changesets creates the tagged GitHub Release. This adds a step that attaches the packed .tgz to that same Release, so the GitHub Release tarball distribution channel stays in sync with npm automatically — no separate tag push or manual release-tarball.yml run.

How

• Added id: changesets to the existing publish step to read its outputs.
• New step gated on steps.changesets.outputs.published == 'true' so it only runs on an actual publish (not when the action is just opening/updating the version PR).
• Reads the version from publishedPackages, reconstructs the tag anarchitecture-ghost@<version> (the format Changesets already uses — see the existing anarchitecture-ghost@0.1.0 tag), packs the tarball, and gh release upload --clobber attaches it.
• Defensive guard: if the Release doesn't exist yet, create it first so the release never fails on a tooling change.

Why

Today npm publish (release.yml) and the GitHub Release tarball (release-tarball.yml) are two independent pipelines. The tarball one only fires on a manually pushed tag, so the GitHub Release tarball lags behind npm. Consumers that pin a GitHub Release url + sha256 (e.g. Homebrew-style manifests) end up pointing at versions that were never released as tarballs. This couples the two so a single merge keeps them aligned.

Notes

• release-tarball.yml is now redundant for the tag-push path; it can be kept as a manual workflow_dispatch fallback or have its push: tags trigger dropped to avoid double-runs. Left as-is for now.
• Forward-looking only — does not retroactively create older Releases.
• Workflow YAML can't be fully validated locally; worth watching the next release run.