ci: bring consumer-verify onto main, pinned to an immutable shared-workflow ref

The dev copy of this workflow called the shared verifier at @dev, a moving
ref, and (in three repos) carried a torn cron -- the schedule's MM HH had
been transplanted onto the bundle_image line, leaving 'cron: " * * *"'
(invalid) and a bundle_image that named a time of day instead of an image.

This is a clean copy for main: the original per-repo cron spread is
restored so the fleet does not stampede the schedule at once, bundle_image
is restored to the value the repo's artifacts actually call for, and the
shared workflow is pinned to ceb7104a4cdb06f3bba20b68c6c1a76fac2215f7 --
the tip of plugin-consumer-verify.yml as of busbar v1.5.4. The v1.5.4 tag
itself does not carry the file, so the commit SHA is the immutable pin.

Author: MattJackson

.github/workflows/consumer-verify.yml

@@ -0,0 +1,66 @@
+name: consumer-verify
+
+# Does what this repo PUBLISHED actually work when a user gets it?
+#
+# Every other workflow here reports on itself. ci.yml proves the code builds and its tests pass.
+# release.yml's verify-assets proves the upload step believed it succeeded, asserted from inside the
+# run that did the uploading. None of that is evidence about the artifact a user downloads, and the
+# gap is not theoretical: webrequest-hook v1.0.4 published as a zero-asset phantom, and
+# headroom-hook's published bundle could not boot the gateway because its shipped config used shapes
+# busbar 1.5.3 retired. Both were green everywhere. Nothing anywhere noticed.
+#
+# The logic lives in ONE place for the whole fleet, exactly like plugin-ci.yml, so a fix reaches
+# every plugin at once instead of being copied ten times and drifting nine.
+#
+# WHY BOTH TRIGGERS. release: published catches a broken publish immediately, and it fires whether or
+# not the release workflow itself finished happy - which matters, because a verifier that only runs
+# when everything already worked is not a verifier. The daily schedule catches ROT: an artifact that
+# published fine can stop working later when nothing about it changed (a bundle that no longer boots
+# against a newer engine, an asset deleted by hand, a release un-flagged as latest). A
+# publish-time-only check structurally cannot see that class.
+on:
+  release:
+    types: [published]
+  schedule:
+    - cron: "3 10 * * *"
+  workflow_dispatch:
+    inputs:
+      version:
+        description: "Version to verify (e.g. 1.0.4). Empty means the newest published release."
+        required: false
+        type: string
+
+permissions:
+  contents: read
+  issues: write
+  actions: read
+
+jobs:
+  consumer:
+    # Pinned to an IMMUTABLE ref, never @dev: the verdict must not change because the shared
+    # workflow moved. This SHA is the tip of plugin-consumer-verify.yml as of busbar v1.5.4
+    # (the file is not carried by the v1.5.4 tag itself, so the commit SHA is the pin).
+    uses: GetBusbar/busbar/.github/workflows/plugin-consumer-verify.yml@ceb7104a4cdb06f3bba20b68c6c1a76fac2215f7
+    with:
+      version: ${{ inputs.version || '' }}
+      # Read off the PUBLISHED artifact, not guessed from the crate name: the filename prefix and the
+      # manifest name genuinely differ across this fleet (the store repos drop the trailing -plugin
+      # that the auth repos keep, and store-valkey publishes as busbar-store-redis).
+      # THE VALKEY IDENTITY, NOT THE RETIRED REDIS ONE. release.yml packs
+      # `--name busbar-store-valkey-plugin --alias valkey` and uploads
+      # busbar-store-valkey-<ver>-<target>.tar.gz, which is the stem busbar itself resolves
+      # (crates/busbar/src/config/mod.rs STORE_MODULE_VALKEY_ASSET_STEM). These three inputs were
+      # still naming the `redis` identity that v1.0.4 retired, so the consumer check was fetching
+      # an asset that has not existed since -- a gate aimed at a name nothing publishes cannot
+      # report on the artifact users actually get.
+      asset_prefix: busbar-store-valkey
+      plugin_name: busbar-store-valkey-plugin
+      plugin_alias: valkey
+      plugin_kind: store
+      # EMPTY, and correct: this repo publishes exactly one kind of artifact, a signed
+      # busbar-store-*.tar.gz per target (see release.yml's `plugin-dist/*.tar.gz` upload) -- no
+      # container bundle anywhere in this repo's workflows. `bundle_image: ""` makes the shared
+      # workflow declare the runnable-bundle boot check NOT-APPLICABLE rather than silently skip it.
+      bundle_image: ""
+      bundle_env: ""
+    secrets: inherit