Cut a release once a week, and only when there is something in it

Publishing on release is the right trigger only if releases happen. They had
not: main ran 184 commits ahead of the last one, so `:latest` described a
build that neither the demo, nor production, nor anyone building from source
was running. This is the part that makes the trigger true without anyone
having to remember.

Mondays at 09:00 UTC. A run with no commits since the last release does
nothing at all -- an empty release moves `:latest` to an identical build,
spends a version number and mails every watcher about nothing. The decision is
written to the run summary either way, so a quiet week reads as a decision
rather than as a workflow that failed silently.

The awkward part is that a release created with GITHUB_TOKEN raises no
`release` event: GitHub refuses to let a token trigger another workflow, to
stop a workflow looping on its own output. A scheduled job that cut a release
and left publish.yml to notice would tag the commit and never build an image,
which is the kind of failure that looks like success. So publish.yml gains a
`workflow_call` trigger and this calls it directly. The alternative was a
personal access token kept as a secret; this needs no credential.

Two smaller decisions. Drafts are excluded when looking for the last release,
because an unpublished draft is not a release anybody has and counting from it
would hide commits that never shipped. And if the tag a release names has
gone, the count falls back to the whole history -- over-counting cuts a
release that was due anyway, where under-counting skips one that was not.

.github/workflows/publish.yml

@@ -26,6 +26,23 @@ name: Publish image
 on:
   release:
     types: [published]
+  # Callable, so release.yml can build the release it just cut. This is not a
+  # stylistic choice: a release created with GITHUB_TOKEN does **not** raise a
+  # `release` event -- GitHub refuses to let a token trigger another workflow,
+  # to stop a workflow looping on its own output. A scheduled job that cut a
+  # release and expected this file to notice would silently never publish. The
+  # alternatives are a personal access token kept as a secret, or calling the
+  # workflow directly. This is the one that needs no credential.
+  workflow_call:
+    inputs:
+      ref:
+        description: "Tag, branch or SHA to build"
+        required: true
+        type: string
+      tag_latest:
+        description: "Also move :latest to this build"
+        type: boolean
+        default: false
   # Same reasoning as ci.yml's dispatch trigger: a run GitHub queues and then
   # orphans can be neither rerun nor cancelled, and this workflow otherwise
   # only fires on a release -- which is not something to cut twice because a