a docs commit rebuilt and re-signed a binary that had not changed

Publishing a rolling build on every push to main meant a README edit
produced a new signed artifact identical to the last one. That is not
just waste: a release appearing says something shipped, and nothing had.

The obvious fix is a paths-ignore on the push trigger, and it is wrong.
A path filter under `on.push` cannot be scoped to branches, so it would
sit in front of the tag trigger too, and a tag usually points at a commit
that was already pushed. Whether GitHub considers such a push to have
changed any files is not something worth learning by cutting a release
and watching nothing happen.

So the two triggers stop sharing an event. release.yml keeps the tag
trigger and gains workflow_call; rolling.yml owns main, carries the path
filter, and calls release.yml. One job body, no duplication, and the
github context in a called workflow belongs to the caller, so the
branch-vs-tag branch inside it still sees exactly what it saw before.

Nothing under an ignored path can reach the binary. The assets that do
are compiled in from assets/, which is not ignored, and ci.yml has no
path filter at all, so the tests that read README.md still run on every
push regardless of what this skips.

actionlint covers the new failure mode too, verified by sabotage:
removing workflow_call from release.yml makes it report that rolling.yml
calls a workflow that cannot be called. 133 tests, 3 workflows clean.

Author: Letdown2491

.github/workflows/release.yml

@@ -6,12 +6,14 @@ on:
   push:
     tags:
       - "v*"
-    # main is the rolling channel. kuma is consumed by rebuilding
-    # constantly, so waiting for a tag to get a usable binary would mean
-    # the published one is nearly always behind the tree it is meant to
-    # build from.
-    branches:
-      - main
+  # The rolling channel calls this workflow instead of sharing its push
+  # trigger. A path filter on `push` cannot be scoped to branches, so
+  # skipping doc-only builds here would also put the filter in front of
+  # every tag, and a tag usually points at a commit that was already
+  # pushed. What GitHub reports as "changed" for that push is not
+  # something to find out by cutting a release and watching nothing
+  # happen. See rolling.yml.
+  workflow_call:
   workflow_dispatch:
 
 permissions:

.github/workflows/rolling.yml

@@ -0,0 +1,25 @@
+name: rolling
+
+# main is the rolling channel. kuma is consumed by rebuilding constantly,
+# so waiting for a tag to get a usable binary would mean the published one
+# is nearly always behind the tree it is meant to build from.
+#
+# Documentation is excluded because rebuilding and re-signing an identical
+# binary says a release happened when nothing shipped. Nothing under an
+# ignored path reaches the binary: the assets that do are compiled in from
+# assets/, and ci.yml has no path filter, so the tests that read README.md
+# still run on every push.
+on:
+  push:
+    branches:
+      - main
+    paths-ignore:
+      - "**.md"
+      - LICENSE
+
+jobs:
+  rolling:
+    uses: ./.github/workflows/release.yml
+    permissions:
+      contents: write
+      id-token: write