ci(ci): clarify release job handling for finished Review issues

.github/workflows/close-solved.yml

@@ -62,16 +62,17 @@ jobs:
           fi
           bun apps/cli/sync-project-fields.ts
 
-  # One timever release per finished topic (every core sub-issue closed),
+  # One timever release per finished topic (every core sub-issue closed) and
-  # tagged at the instant the last core problem closed. It reads the same rule
+  # per finished `Review <N> — <Phase>` issue (every sub-issue closed), tagged
+  # at the instant the last required problem closed. It reads the same rules
   # close-topics uses (apps/cli/topics.ts) straight off the sub-issues, so the
-  # push that finishes a topic releases it in this run — no waiting for Close
+  # push that finishes a topic or review releases it in this run — no waiting
-  # Topics, which chains after this workflow. A problem re-parented into a
+  # for Close Topics, which chains after this workflow. A problem re-parented
-  # `Review <N> — <Phase>` issue still belongs to its topic (recovered from
+  # into a Review issue still belongs to its topic (apps/api/src/reviews.ts),
-  # its parent_issue_removed event), so moving it never rewrites a release.
+  # so moving it never rewrites a topic's release. Reconciling: a run releases
-  # Reconciling: a run releases every finished topic still missing one, so a
+  # everything finished and still missing a release, so a manual dispatch
-  # manual dispatch backfills and a problem closed by hand in the UI is picked
+  # backfills and a problem closed by hand in the UI is picked up by the next
-  # up by the next run. Closing a finished Review issue is Close Topics' job.
+  # run. The docs changelog (deploy.yml) tags each release Topic or Review.
   release:
     needs: close
     # Like close-topics: a partially failed close still closed some issues,