recipe-upgrade: abra recipe release for version bump + upstream release-notes links in PR body

cc-ci recipe-upgrade skill now computes the version via 'abra recipe release --dry-run'
(not a hand-edit) and requires the PR body to link upstream release notes per service.
Bumps the recipe-maintainer submodule pointer to the matching change.

.claude/skills/recipe-upgrade/SKILL.md

@@ -115,7 +115,21 @@ On cc-ci's `~/.abra/recipes/<recipe>` (wrap every abra call per the pseudo-TTY b
   `docker manifest inspect`), then write `image: <image>:<newtag>@<newdigest>`. If the app and its
   digest-pinned sidecars must move together (e.g. immich-server ↔ its `postgres:…-vectorchord…` DB),
   bump them as a matched, compatibility-checked set per the plan.
-- Bump the `coop-cloud.${STACK_NAME}.version` label to the new version string from the plan.
+- **Bump the `coop-cloud.${STACK_NAME}.version` label — COMPUTE the version with `abra recipe release`,
+  do NOT hand-write/sed it.** Run it `--dry-run` so it computes the correct `a.b.c+x.y.z` (the recipe
+  SEMVER bumped per the flag + the app service's image tag, which abra reads from compose) WITHOUT
+  publishing — pick `-x`/`-y`/`-z` from the upgrade's nature per the plan (breaking→`-x` major, new
+  feature→`-y` minor, patch/security→`-z` patch):
+  `script -qec "abra recipe release <recipe> -y --dry-run -n" /dev/null`
+  prints e.g. `INFO dry run: not syncing label 3.4.1+2.26.3 for recipe <recipe>` and changes nothing.
+  Then set that exact computed `a.b.c+x.y.z` as the `coop-cloud.${STACK_NAME}.version` label and commit
+  it on the PR branch (this replaces the old hand-picked-semver step).
+  ⚠️ **Never run `abra recipe release` WITHOUT `--dry-run` here** — a real (non-dry-run) release also
+  tries to PUBLISH (push the new version to the recipe's git origin), and our workflow NEVER pushes the
+  recipe's upstream/`main`; we open a PR from a branch on the mirror. So use release only to COMPUTE the
+  version (so it's correct), keep the existing branch→mirror-PR mechanics, and let the label edit + commit
+  ride on the PR branch as before. (`abra recipe upgrade <recipe> -n` for the image-tag bumps above is
+  unchanged.)
 - `script -qec "abra recipe lint <recipe> -C -n" /dev/null` — fix obvious lint errors; if unfixable,
   record it and continue.
 - Commit on a branch: `git commit -m "chore: upgrade to <new-version>"` (the commit message drives the
@@ -182,9 +196,14 @@ exists for this recipe (branch `upgrade-*`), the new work is pushed onto THAT PR
 updated + re-tested** — one evolving upgrade PR per recipe, not a second parallel one. Only if none
 exists is a fresh `upgrade-<version>` PR opened. Unrelated open PRs (e.g. a backup fix) are **NOT**
 closed or touched — the operator decides on those. The PR's diff is exactly this upgrade against the
-real current upstream main. Capture the `PR_URL`. Optionally export `RECIPE_PR_BODY` first (image-tag
-table + the planned operator-action notes). Re-running with the same target version updates the
-existing same-branch PR rather than duplicating it.
+real current upstream main. Capture the `PR_URL`. Export `RECIPE_PR_BODY` first (image-tag table + the
+planned operator-action notes) — and **the PR body MUST link the upstream release notes**: for each
+upgraded image/service, pull its release-notes URL from the registry `cc-ci-plan/upstream/<recipe>.md`
+(between the current → new version) and include one explicit line per service in the body, e.g.
+`**Upstream release notes:** <service> <old>→<new>: <url>`. These links go in the PR comment/body
+itself (so a reviewer sees exactly what changed upstream) — do NOT relegate them to the plan/report
+only. Re-running with the same target version updates the existing same-branch PR rather than
+duplicating it.
 
 ### 4. VERIFY by running `!testme` ON THE PR (results visible in the PR; iterate ≤3×)
 Trigger the **real** CI on the recipe PR by posting `!testme` — the bridge runs the harness on cc-ci