recipe-upgrade: defer version bump to operator's final 'abra recipe release'

§2 no longer bumps the coop-cloud version label in the recipe PR (no
--dry-run compute, no tag). It records the recommended 'abra recipe release
<recipe> -<x|y|z>' (no --dry-run) in the PR body (§3) as the operator's
final publish step — run after the upstream PR merges, it bumps the label +
tags + pushes in one go. Bumps recipe-maintainer submodule to 9daddac (same
change across its /recipe-upstream, -upgrade-apply, -upgrade-plan, -new-tag).

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

@@ -115,25 +115,26 @@ 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 — 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.)
+- **Do NOT bump the `coop-cloud.${STACK_NAME}.version` label in the PR — record the recommended release
+  bump instead.** The version bump + tag + publish are all done at the very end by a single real
+  `abra recipe release` (run by the operator after the upstream PR merges — see recipe-maintainer's
+  `/recipe-upstream`); the upgrade PR only carries the image-tag + config changes. So **leave the version
+  label untouched** and just **decide the semver bump** from the upgrade's nature per the plan
+  (breaking→`-x` major, new feature→`-y` minor, patch/security→`-z` patch). Put the recommended release
+  command — `abra recipe release <recipe> -<x|y|z>` (NO `--dry-run`) — in the PR body (§3) so the operator
+  can run it verbatim to publish. At release time `abra recipe release` computes the final `a.b.c+x.y.z`
+  from the current label + the flag + the app image tag and syncs the label then.
+  ⚠️ **Never run `abra recipe release` in this skill** (with or without `--dry-run`) — a real release
+  PUBLISHES (pushes the new version to the recipe's git origin) and we NEVER push the recipe's
+  upstream/`main`; we open a PR from a branch on the mirror. Publishing is the operator's final step.
+  (`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
-  PR branch name `upgrade-<new-version>`). Do **not** push to upstream; do **not** tag-push.
+- Commit on a branch describing the image-tag/config changes, e.g.
+  `git commit -m "chore: upgrade <service> to <new-tag>"`. Do **not** mention a recipe version (none is
+  bumped here) and do **not** create/push a tag — the branch name falls back to `upgrade-<short-sha>` (see
+  `open-recipe-pr.sh`). Do **not** push to upstream; the version bump + tag + publish are the operator's
+  final `abra recipe release` step.
 
 ### 2b. Direct deploy + inspect on cc-ci — live feedback BEFORE CI (recipe-maintainer style)
 Before opening the PR / running `!testme`, deploy the WIP recipe **directly** on the cc-ci server and
@@ -202,8 +203,10 @@ upgraded image/service, pull its release-notes URL from the registry `cc-ci-plan
 (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.
+only. The body must **also** carry the recommended release command — `abra recipe release <recipe> -<x|y|z>`
+(NO `--dry-run`) — on its own line, since the PR does not bump the version label: this is the operator's
+final publish step (bumps the label + tags + pushes) after the upstream PR merges. 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