ask for the release on a clock

hanzoai/ci's client lane, given no payload, now reads hanzoai/cloud's newest tag
off git.hanzo.ai and regenerates this tree onto it. This is the trigger that
makes it happen without anybody pressing anything.

It replaces a fan-out that could not work in either direction: cloud pushed
`repository_dispatch: spec-update` at nine projection repos, but github.com has
zero self-hosted runners and these callers ask for the forge's pool, so an
accepted event queued until GitHub cancelled it a day later — and the forge,
which has the runners, has no repository_dispatch endpoint at all. Twelve such
dispatches exist across the fleet and not one reached a first step.

Asking is the better verb even where telling would have worked. It needs no
credential spanning six owners, it runs on the runners that exist, and a release
stays green whether or not this repo is well — a projection that is down is this
repo's problem, not a reason to redden a cloud release that is already live.

.hanzo/workflows/cicd.yml

@@ -20,6 +20,15 @@ on:
     branches: [main]
     tags: ['v*']
   pull_request:
+  # THE PROJECTION ASKS FOR THE RELEASE. hanzoai/ci's client lane, given no
+  # payload, reads hanzoai/cloud's newest tag off git.hanzo.ai and regenerates
+  # this tree onto it. That replaces a fan-out cloud pushed at nine repos and
+  # which never once reached a first step — github.com has no runner for the
+  # label these callers ask for, and the forge, which does, cannot receive a
+  # repository_dispatch at all. Asking needs no credential spanning six owners,
+  # and a release stays green whether or not this repo is well.
+  schedule:
+    - cron: '19 7 * * *'
   workflow_dispatch:
 jobs:
   cicd: