fix(gitea-releases): restore the prerelease imperative to the create path

The retrofit left only a descriptive sentence on the loaded path — "Gitea
never infers a prerelease from a -beta/-rc tag name" — and moved the
imperative into references/conventions.md behind a trigger listing semver
naming, release-notes sourcing and release-to-tag relationships. Draft and
prerelease are not in that list, and "cut a v2.0.0-beta.1" is exactly the
request where the caller does not raise the topic, so the rule was
unreachable from the flow that needs it.

Severity comes from the repair path: the MCP surface has create, get,
get_latest, list and delete only — there is no update or edit tool. A
release published without is_pre_release can only be corrected by
delete_release plus a fresh create, and get_latest_release points
consumers at the beta meanwhile. Neither SKILL.md nor call-signatures.md
said so anywhere.

The flags are now set explicitly on every create, the missing update tool
and its delete-and-recreate consequence are stated in the body, and the
semver pass-through rule stranded behind the same trigger is promoted
alongside it. call-signatures.md now cites the deployed tool description
as direct evidence that get_latest_release excludes drafts, while keeping
the prerelease half hedged — that remains unconfirmed.

Verified live against gitea-mcp v1.7.0, read-only calls.

Refs #99

plugins/gitea/.apm/skills/gitea-releases/references/call-signatures.md

@@ -32,7 +32,7 @@ for brevity.
 
 **`get_latest_release`**
 - No parameters beyond `owner`/`repo`.
-- Returns a single release object for the most recently published release. It is assumed (by analogy with typical "latest release" semantics) that this excludes drafts and prereleases, but that exclusion is not directly confirmed by any of the research docs — verify with `list_releases` if the caller depends on this.
+- Returns a single release object for the most recently published release. The deployed tool's own description reads "the most recent published (non-draft) release" — it names drafts as excluded and is silent on prereleases, so whether prereleases are also excluded is *unconfirmed*; verify with `list_releases` if the caller depends on it. Either way a release created without `is_pre_release: true` is eligible, which is why that flag has to be set in the create call (see `conventions.md`).
 
 **`create_release`**
 - Required: `tag_name` (string), `target` (string — branch, tag, or commit SHA to cut the tag from), `title` (string)

plugins/gitea/.apm/skills/gitea-releases/references/conventions.md

@@ -33,6 +33,13 @@ commonly used to signal a prerelease to humans. When a user asks to "cut a beta"
 release candidate," set `is_pre_release: true` explicitly in the same call rather than relying on
 the tag string to carry that meaning.
 
+Getting this wrong is not cheaply repairable. The gitea-mcp release surface is `create_release`,
+`get_release`, `get_latest_release`, `list_releases` and `delete_release` — there is **no update or
+edit tool**, so a published release's flags cannot be corrected in place. The only remedy is
+`delete_release` plus a fresh `create_release`, a destructive round trip; meanwhile a beta published
+without `is_pre_release` is the release `get_latest_release` returns. Set the flags in the create
+call.
+
 Note the input/output naming mismatch: the input param is `is_draft`, but the release object
 returned by the API uses `draft` (and `prerelease`) as the field names. `draft` is never a valid
 input key — passing `draft: true` to `create_release` is silently ignored rather than erroring.