Add Changesets-based release tracking without forking changesets/action

[Copilot]

Dependabot and other PRs routinely merge without changesets, and package.json (0.3.1) had drifted from the latest published/tagged release (v0.4.0) because the old release-triggered workflow never wrote the published version back to the repository.

This PR introduces a standard Changesets release-PR flow using the unmodified changesets/action@v2, plus a repository-local script that creates automatic patch changesets for unreleased commits when contributors have not supplied an explicit changeset.

Version baseline

• Reconciles package.json and package-lock.json to 0.4.0, matching the existing v0.4.0 release tag.

Release preparation

scripts/prepare-release.mjs:

• Gives explicit changesets precedence, preserving contributor-selected version bumps and release notes.
• Resolves the current release as v${package.json.version}.
• Skips automatic generation when that tag does not exist, preventing another version bump while a release is pending publication.
• Reads first-parent history from ${tag}..HEAD.
• Extracts PR numbers and titles from merge and squash commits, falling back to the commit SHA and subject.
• Creates one deterministic .changeset/auto-release-<sha>.md patch changeset per unreleased entry.
• Removes stale automatic changesets before regenerating them.
• Fails with an actionable message when run from a shallow clone.

Each generated changeset contains one release entry without its own Markdown list marker:

---
"@github/remote-input-element": patch
---

[#53](https://github.com/github/remote-input-element/pull/53) [`abc1234`](https://github.com/github/remote-input-element/commit/abc1234...) - Bump the npm_and_yarn group

Keeping each entry in a separate changeset allows Changesets to render every change at the same top-level list depth while still producing a single patch release for the package.

Release policy

• Substantive non-dependency changes are released immediately.
• Security dependency updates are released immediately.
• Non-security dependency-only updates wait until the current release is at least 30 days old.
• The dependency release age can be configured through DEPENDENCY_RELEASE_AGE_DAYS.

Security updates are detected from security or vulnerability labels, Security sections in the PR body, and CVE or GHSA identifiers.

Workflow changes

• Adds .github/workflows/release.yml, triggered by pushes to main and workflow_dispatch.
• Checks out the complete Git history and tags with fetch-depth: 0.
• Installs dependencies and runs the test suite before preparing a release.
• Runs npm run prepare-release.
• Uses the standard changesets/action@v2 action to open or update a Release tracking pull request or publish the package.
• Uses the Changesets v2 inputs pr-title, commit-message, and publish-script.
• Removes the old release-triggered publishing workflow to prevent duplicate or competing publication paths.
• Preserves npm provenance and the existing GitHub Packages post-publish behavior.
• Updates the PR workflow to run the release-preparation tests.

Configuration and documentation

• Adds .changeset/config.json with public package access, the GitHub changelog generator, and main as the base branch.
• Adds @changesets/cli and @changesets/changelog-github as development dependencies.
• Adds prepare-release, changeset, and release package scripts.
• Documents explicit changesets, automatic patch entries, dependency gating, manual workflow runs, and the release-PR process in README.md.

Tests

scripts/prepare-release.test.mjs covers:

• Pending-publication detection when the expected tag is absent.
• No changes since the current release tag.
• Explicit changeset precedence.
• PR-linked and commit-only release entries.
• One deterministic automatic changeset per release entry.
• Flat release-note formatting without duplicate list markers.
• Idempotent regeneration.
• Stale automatic changeset cleanup.
• Repository URL normalization.
• Security-update detection.
• The 30-day dependency-only release threshold.
• Immediate security dependency releases.
• Immediate substantive releases.
• Multiple patch changesets targeting one package release.