feat: mark patch releases as prereleases, org-wide

[toastygm]

The release workflow invoked softprops/action-gh-release@v3 with tag_name,
name, body_path and files and no prerelease: input, so every release
every Foundry package cut published as an ordinary release and GitHub promoted
it to "Latest".

The rule

Patch releases are all marked prerelease, period. No exceptions. Only major
and minor releases are marked release. X.Y.Z with Z non-zero publishes as
a GitHub prerelease; X.Y.0 publishes as a normal release.

Org-wide, not a per-package opt-in, and it applies to future releases only —
nothing already published is relabelled.

Why

The semver digits carry a release channel, not a severity: minor/major
goes to users, patch is beta and is never meant to be consumed. 0.9.1,
0.9.2, … accumulate toward the next user release, which one minor then cuts
as 0.10.0.

The channel lives in the digits rather than in a semver prerelease component
because Foundry has to sort these: its versions are <major>.<build> and
isNewerVersion is a naive dot-split with a string fallback, so 0.9.0-beta.0
would sort wrongly against 0.9.0. Numeric-only sorts correctly; what it cannot
do on its own is say which channel a version is on. The GitHub label is what
says that to a human — and today it says the opposite.

What the decision is keyed on

steps.decide.outputs.version — the value that step already reads from
package.json — not the tag string. The tag is that same value with a v glued
on; re-parsing it would mean stripping a prefix the step added itself, and would
make the rule depend on the tag spelling rather than on the version.

Inputs, verified

Both names checked against softprops/action-gh-release's own action.yml at
the v3 tag (5113cdc), per the standing rule this workflow already carries:

• prerelease — "Identify the release as a prerelease. Defaults to false".
  Parsed as INPUT_PRERELEASE == 'true'; anything else is false.
• make_latest — "Can be true, false, or legacy… Drafts and prereleases
  cannot be set as latest. Uses GitHub api default if not provided." Parsed by a
  literal match on those three strings and ignored otherwise.

Both are set together and always explicitly, because both defaults are wrong
here: the action defaults prerelease to false and GitHub defaults make_latest
to true, so an unlabelled patch would be published as the current release and
would take the Latest badge off the last real one. Labelling the prerelease while
leaving Latest to the default fixes only half of it. The decide step emits the
literals rather than a ${{ … && … || … }} ternary over prerelease.

The decision table

Driven over the logic extracted verbatim from the committed workflow:

version	exit	prerelease	make_latest	published as
0.9.0	0	false	true	release, Latest
0.9.1	0	true	false	prerelease
0.10.0	0	false	true	release, Latest
1.0.0	0	false	true	release, Latest
0.0.1	0	true	false	prerelease
0.5.3	0	true	false	prerelease
0.9.10	0	true	false	prerelease
10.0.0	0	false	true	release, Latest
1.2.3.4	1	—	—	run fails
1.0.0-beta.1	1	—	—	run fails
0.9	1	—	—	run fails
01.2.3 / 1.02.0	1	—	—	run fails
v0.9.1	1	—	—	run fails
0.9.0+build.5	1	—	—	run fails
1.2.x, empty	1	—	—	run fails

A malformed version fails the run

The parse is strict — exactly three dot-separated numeric components, no leading
zeros — and it fails closed, like every other guard in this file. A version
it cannot classify stops the run rather than falling through to "release",
because "release" is the outcome with consequences: it is published the instant
it exists, it takes the Latest badge, and every installed copy updates from it.
An unclassifiable shape must not be resolved by guessing the irreversible answer.

It also catches the specific mistake this scheme invites — a 1.0.0-beta.1
written by someone reaching for changesets' prerelease mode, which is exactly
the spelling Foundry mis-sorts.

Blast radius — stated plainly

Other packages have already shipped patch releases as ordinary releases:

• sohl-kethira-basic — v0.5.1, v0.5.2, v0.5.3
• harn-adventures — v0.0.1

After this change, their next patch release publishes as a prerelease. That
is the intended consequence of an org-wide rule, not a regression. No existing
release is relabelled — published releases are history.

Verification

• Decision logic extracted verbatim from the committed workflow and driven over
  the table above.
• prerelease and make_latest confirmed from the action's own action.yml at
  the v3 tag, not from memory.
• actionlint (1.7.12, with shellcheck integration) clean on this file and on
  every workflow in the repository.
• The file parses as YAML and the two new inputs resolve on the release step.
• No consumer repository touched.

Closes #26