fix(ci): revert changesets/action to v1.9.0 and ignore its majors

[agjs]

Summary

• Fixes the release workflow failing on main (run 31777307881) by reverting changesets/action to the exact SHA main ran before chore(deps): batch the post-#361 Dependabot wave #384.
• Adds a Dependabot major-ignore so it stops being re-proposed.

What broke

#384 took changesets/action v1.9.0 → v2.0.0. v2 renames every input, so the existing with: block became invalid the moment it merged:

##[error]The following inputs have been renamed:
  - "publish" -> "publish-script"
  - "version" -> "version-script"
  - "commit" -> "commit-message"
  - "title" -> "pr-title"
  - "createGithubReleases" -> "create-github-releases"

Dependabot bumped a major action version while leaving the inputs untouched — the bump is a one-line SHA change, so nothing signalled that the call site needed rewriting.

Why v2 isn't just an input rename

Three things block it beyond the renames, from the v2.0.0 release notes:

1. It requires Changesets CLI v3. v2 validates this at runtime and explicitly directs CLI v2 users back to @v1. apps/ui is on @changesets/cli 2.31.0, so v2 would refuse regardless of how the inputs are written.
2. cwd was removed. This monorepo depends on it — .changeset/ lives in apps/ui, not the repo root. There is no root-level changesets setup for the action to find.
3. Custom scripts must thread CHANGESETS_OUTPUT. Published-package detection moved from stdout parsing to a shared output file, and our version/publish are custom (bunx changeset version / bunx changeset tag).

So this is a deliberate piece of work alongside the CLI v3 upgrade, not a dependency bump. The ignore entry mirrors @astrojs/cloudflare and elysia-rate-limit, both held back for the same reason: a major that needs a migration we haven't done.

Why PR CI didn't catch it

apps-ui-release.yml only runs on push to main. No PR-triggered workflow exercises it, so a broken release config cannot fail a PR — it can only fail after merge. I flagged this action as unverified in #384's description but still let it into the batch; I should have checked the CLI-version constraint before including it, since the release notes state it plainly.

Worth considering separately: a lint step that diffs an action's declared inputs against its with: block would catch this class of failure at PR time. Happy to open an issue if you want it tracked.

Test plan

• Reverted SHA is byte-identical to what main ran at 7ebe038 (pre-chore(deps): batch the post-#361 Dependabot wave #384) — verified with git show 7ebe038:.github/workflows/apps-ui-release.yml
• The v1-style with: inputs are unchanged, so the call site matches v1.9.0's contract again
• dependabot.yml parses; the new entry sits in the github-actions ecosystem block
• release workflow goes green on the merge commit — this is the real confirmation, and it can only be observed after merge

No app code touched; bun run check surface is unaffected.

Conventions

• No any / as / ! — no TypeScript changed
• No env var changes
• Tests updated for changed behavior — n/a, CI config only

Screenshots

Not applicable.