Community catalog workflows: make tag-pinned download_url a MUST and reject `releases/latest/`

Problem

The community-catalog agentic workflows only softly require a version-pinned download_url. Step 2d currently says the URL "should follow the pattern" — advisory language an autonomous run can rationalize around.

This surfaced in PR #4183 (update speckit-superpowers-bridge to v1.2.0), where the run switched the URL to a floating "latest" alias and validation passed it:

- .../releases/download/v1.1.0/speckit-superpowers-bridge-v1.1.0.zip   (tag-pinned)
+ .../releases/latest/download/speckit-superpowers-bridge.zip          (floating "latest")

…/releases/latest/download/… is neither of the two accepted tag-pinned patterns. It resolves to whatever the newest release happens to be, not to the <tag> (v1.2.0) recorded in the entry — so the catalog would keep serving the author's future releases under the pinned "version": "1.2.0" record. That's an integrity/reproducibility hole and breaks the convention (all existing catalog download_urls are tag-pinned; none use releases/latest).

The run passed validation because the checks only confirmed the URL returns HTTP 200 and that a v1.2.0 release exists — neither verifies the URL is pinned to the v1.2.0 tag.

Affected workflows

Same soft wording appears in all three community-catalog workflows:

• .github/workflows/add-community-extension.md:110
• .github/workflows/add-community-bundle.md:123
• .github/workflows/add-community-preset.md:164

Proposed changes

1. Change "should follow the pattern" → MUST for the tag-pinned download_url requirement in all three workflows.
2. Add an explicit rejection rule: a download_url whose path contains releases/latest/ fails validation, even if it returns HTTP 200.
3. Strengthen the release check to verify the URL's <tag> segment matches the submitted v<version> (not just that a release exists and a URL 200s).

Accepted URL patterns (unchanged)

• https://github.com/<owner>/<repo>/archive/refs/tags/v<version>.zip
• https://github.com/<owner>/<repo>/releases/download/<tag>/<asset>.zip

Context

• PR #4183