Publish workflow never rebuilds the image between releases, and `latest` has never been published

### Feature area

Other

### Description

`.github/workflows/docker-publish.yml` publishes `ghcr.io/koala73/worldmonitor` on `release: published` and on a manual dispatch only. Add a weekly `schedule:` so the image is rebuilt from `main` on a fixed cadence, and let `latest` follow the default branch as well as a release.

### Problem it solves

Nothing rebuilds the image between two releases, so its age has no ceiling. What the package holds today:

```console
$ TOKEN=$(curl -s "https://ghcr.io/token?scope=repository:koala73/worldmonitor:pull&service=ghcr.io" | jq -r .token)
$ curl -s -H "Authorization: Bearer $TOKEN" https://ghcr.io/v2/koala73/worldmonitor/tags/list
{"name":"koala73/worldmonitor","tags":["sha-d59e413","sha-6c48a33"]}
```

Two `sha-*` images, both built **2026-07-05** (~2 months old), and **no `latest`, no semver tag**:

- `type=raw,value=latest` is gated on `github.event_name == 'release'`, and the last release is v2.5.23 (2026-03-01) — the release trigger has not fired since. Both existing images came from a manual dispatch, which produces neither `latest` nor a semver tag.
- So `docker pull ghcr.io/koala73/worldmonitor` resolves nothing at all today.

The fixes that would make a rebuild worthwhile do reach `main`, and stop there: PR #7602 moved the nginx base digest in `docker/Dockerfile` on 2026-09-04. That fix is on `main` and in nothing anyone can pull.

Reading the age back off the registry is impossible too: the workflow computes the OCI labels with `docker/metadata-action` and never passes them to `docker/build-push-action`, so the only label on either published image is `maintainer`, inherited from the nginx base — no `org.opencontainers.image.created`, no `.revision`.

### Alternatives considered

**Rebuild the last release tag instead of `main`**, the way a "base image refresh" workflow usually works: resolve the base image's current digest, compare it with the digest recorded on the published image, rebuild when it moved. That cannot work here, and this repository's own guards are the reason: both FROM lines in `docker/Dockerfile` are pinned to an immutable digest, and `tests/ci-workflow-coverage.test.mts` ("keeps Docker base images pinned to immutable digests") requires they stay pinned. A pinned base never moves, so rebuilding a tag verbatim reproduces the same image byte for byte. A base fix reaches the image only once Dependabot has moved the pin on `main` — which is where a scheduled rebuild has to read from.

**Cut releases again.** That would fix it too, but it ties image freshness to release cadence, which is the thing that stalled in March.

### Additional context

I have a branch ready and will open it as a PR against `main`: the weekly `schedule:`, `latest` following the default branch, the labels/annotations actually handed to the build, plus a daily Dependabot interval for the `github-actions` and `docker` ecosystems and auto-merge for the grouped minor/patch action bumps. The npm and cargo entries are left exactly as PR #7554 set them.

Happy to split it if you would rather review the rebuild on its own.

Start with .github/workflows/docker-publish.yml and inspect its release and manual-dispatch triggers, metadata, and build steps. Run tests/ci-workflow-coverage.test.mts while checking the workflow changes. Done means scheduled main rebuilds, default-branch images receive latest, and the generated OCI labels reach the published image.

Written by the indexing model from the issue text.