Bumps [postcss](https://github.com/postcss/postcss) from 8.5.8 to 8.5.12.
- [Release notes](https://github.com/postcss/postcss/releases)
- [Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md)
- [Commits](postcss/postcss@8.5.8...8.5.12)

---
updated-dependencies:
- dependency-name: postcss
  dependency-version: 8.5.12
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…-baseline warnings (#1570)

* feat: switch PR discovery from date-based to SHA-based commit range

Replaces `Commit.history(since: lastRelease.created_at)` with `Ref.compare(headRef)`
to fix missed PRs when using rebase merge, where commit authored dates can predate
the release timestamp. The new approach is purely graph-based with no date boundary.

Fallback chain when no previous release tag exists:
1. Most recent git tag → compare against it
2. No tags at all → cap-and-bail (single page fetch; empty result if history exceeds
   limit, uses `initial-commits-since` as the only remaining date boundary)

Path filtering (`include-paths`/`exclude-paths`) also switches to SHA-based: instead
of `since`, `Commit.history(path:)` is paginated and stops as soon as a page returns
no commits in the comparison set, using the in-memory SHA set as the boundary.

Also adds `executeGraphql` helper to eliminate `print()` calls and explicit type
parameters at GraphQL call sites, and switches all queries to typed-document-node
codegen.

* fix: only collect commit authors as contributors when the commit has an associated PR

Previously, commit authors were added to the contributors list regardless of whether
the commit was associated with a pull request. This meant direct pushes to the branch
(commits with no PR) would incorrectly appear as contributors even though they had no
corresponding changelog entry.

The date-based filtering in the old Commit.history approach accidentally masked this
bug — commits without a committedDate were silently dropped by the since filter.
Switching to the SHA-based Ref.compare approach removed that accidental filter and
exposed the issue.

Now contributors from commits are only collected when the commit has at least one
associated pull request, keeping the contributor list consistent with what appears
in the changelog.

* feat: append warnings to the release body when no previous published release exists (#1573)

* feat: append warnings to the release body when no previous published release exists

Prevents fetching endless commits and associated pull requests when no previous published release can be found, and used as a baseline to compare with current commitish's HEAD. This warning redirects to a newly introduced issue template that both guides user towards stating their issue, aswel helping them understand what has happened.

* refactor: remove initial-commits-since input and config

* test: update tests to reflect new comparison (only) commit fetching

* docs: mention how parsing the commitish could be enhanced (TODO)

* fix: remove unused import

* chore: update coverage & dist

* refactor: fully remoce initial-commit-since

---------

Co-authored-by: Clément Chanchevrier <67628843+cchanche@users.noreply.github.com>
Co-authored-by: Clément Chanchevrier <clement.chanchevrier@gmail.com>
Co-authored-by: Joseph Petersen <me@jetersen.dev>

Co-authored-by: jetersen <1661688+jetersen@users.noreply.github.com>
Co-authored-by: Clément Chanchevrier <67628843+cchanche@users.noreply.github.com>

#1605)

…s exist (#1602)

* fix: restore prerelease-identifier on first run when no prior releases exist

When no prior release exists and no input version is provided, the else
branch in getVersionInfo forced _localIncrement to 'no_increment', which
made $RESOLVED_VERSION return a bare version (e.g. '0.1.0') regardless
of the prerelease-identifier and versionKeyIncrement config.

This broke workflows that rely on prerelease-based increments
(prepatch/preminor/premajor) to produce an RC-tagged version on first
run (e.g. '0.1.0-rc.0').

Root cause: the v6 code (lib/versions.js, PR #1303) explicitly handled
this case — when versionKeyIncrement started with 'pre', it returned the
hardcoded $NEXT_PRERELEASE_VERSION default ('0.1.0-rc.0') as
$RESOLVED_VERSION. That behaviour was lost during the v7 TypeScript
rewrite (PR #1475).

Fix: when no prior release exists, versionKeyIncrement starts with
'pre', and prerelease-identifier is set, initialise the reference
version directly as '0.1.0-<identifier>.0' and use no_increment. This
produces $RESOLVED_VERSION = '0.1.0-rc.0', matching v6 behaviour.
When no prerelease-identifier is set, or the increment is not
prerelease-based (patch/minor/major), behaviour is unchanged.

  prepatch/preminor/premajor + identifier 'rc', no prior release:
    before: 0.1.0   (prerelease-identifier ignored)
    after:  0.1.0-rc.0

  patch/minor/major, no prior release: 0.1.0 (unchanged)

Note: the semantic question of whether premajor on first run should
produce '1.0.0-rc.0' rather than '0.1.0-rc.0' is a pre-existing
limitation that also existed in v6 and is tracked separately.

* chore: rebuild dist for prerelease-identifier first-run fix

---------

Co-authored-by: Joseph Petersen <me@jetersen.dev>

Co-authored-by: Clément Chanchevrier <67628843+cchanche@users.noreply.github.com>