docs: clarify when to split the PR check into its own workflow

[theoephraim]

What

Two doc fixes to the GitHub Actions / snapshots guidance, both prompted by realizing the reasons to prefer a dedicated bumpy ci check workflow weren't written down anywhere — so the docs lead with "inline step" while careful reasoning keeps rediscovering the dedicated-workflow case, making them look like they contradict each other.

1. docs/github-actions.md — "Inline step vs. dedicated workflow" callout

Adds a short note under the PR-check section explaining when to give ci check its own on: pull_request workflow instead of folding it into existing CI:

• Slow CI + fork comments — the workflow_run poster fires on whole-workflow completion, so an emit step buried in a multi-minute CI workflow delays the release-plan comment until lint/typecheck/build/tests all finish. A dedicated check (no bun install) posts in seconds. This is the one reason that specifically argues for a separate file rather than just a separate job.
• Load-bearing gate — an early inline ci check that exits non-zero on a missing bump file fails the job and skips the test run, so contributors who push before adding a bump file lose all test signal. A separate workflow (or job) keeps the gates independent.

Keeps the inline step as the documented default — this just helps readers self-select.

2. docs/snapshots.md — fix stale pull_request_target cross-reference

The fork note pointed at "the same pull_request_target caveats … as for the check comment," but the check comment no longer uses pull_request_target — it uses the pull_request + workflow_run split. Updated the wording and pointed the link at the #commenting-on-fork-prs anchor.

Why

Docs-only. No behavior change.