When the Upgrade Notice section already contained an entry for the
release version with no later "= <digit>" heading after it, the lazy
match in update-upgrade-notice.js ran all the way to EOF — wiping out
the "== Changelog ==" heading and everything after it. The downstream
update-readme-changelog.js then threw "Could not find '== Changelog ==' "
and update-release-pr.yml exited non-zero before committing the
Version: / Stable tag: bumps that had already been written to disk.

This is what stranded the wp-graphql-ide 5.0.0 release with Version: 4.5.0
and Stable tag: 4.5.0 inside the SVN tag the wp.org deploy created at
/tags/5.0.0/ — producing the author-only "Version header does not match
the SVN tag" warning on the plugin page.

Add the next "== " major-section heading to the existingNoticeRegex
lookahead so the match stops at "\n== " too. Add a regression test that
reproduces the PR #3892 shape (existing "= 5.0.0 =" notice immediately
followed by "== Changelog ==" with no later "= <digit>" heading) and
asserts the Changelog section survives. Also tighten the existing test 4
to assert the same.

Bump the IDE plugin's Version: header, WPGRAPHQL_IDE_VERSION constant,
and readme.txt Stable tag: from 4.5.0 to 5.0.0 — the post-state the
workflow would have left behind if it had completed — so the next
deploy ships matching metadata. The next release-please cycle will
exercise the fixed flow end-to-end.

Per code-review feedback on the initial regex tweak: the underlying
brittleness is doing the replace against the full readme.txt content.
Even with the `\n== ` lookahead, the inner lazy match could still
escape the section in pathological cases — and `==Heading==` written
without spaces (which wp.org's readme parser accepts) bypasses the
lookahead entirely and re-creates the original bug.

Restructure so the replace operates on `upgradeNoticeMatch[2]` (the
captured section body) and splices the modified body back. The outer
regex already bounds the body slice at `\n==` (no space required), so
the inner replace is structurally incapable of corrupting a sibling
section regardless of which alternative its lookahead ultimately
matches.

Anchor `versionNoticeRegex` to a line start (`(^|\n)= X.Y.Z =`) so a
prose mention like "upgraded from = 5.0.0 = to ..." can no longer
false-positive into the "replace existing notice" branch.

Add Test 8b (no-space `==Changelog==` still bounded correctly) and
Test 8c (prose mention doesn't trigger the replace path).

Matches the trim done on update-readme-changelog.js. Keeps only the
why-is-this-code-shaped-this-way notes; the IDE 5.0.0 incident story
and the prose-mention example live in the PR description and git log.