fix(bundle): publish to a bundles branch, and unbreak the stale check

Three things, all found by the first compose run that ever had a bundle
to write.

1. `main` is protected, so the push was declined by the pre-receive
   hook -- twice, since the retry rebases and pushes to the same place.
   Every bundle since v1.1.1 has been composed correctly and thrown
   away. Bundles now go to a `bundles` branch of their own, at its
   root, which needs no protection exception and keeps everything the
   original choice was for: a reviewable diff, a git history of the
   compat matrix, plain anonymous raw URLs, no credentials on the shard
   host. The header's claim that this push "needs no new
   branch-protection exception" was simply false.

2. A `${{ }}` written literally in a shell comment silently disabled
   the entire stale-component check. The runner scans a step's script
   for template expressions before running it, fails to parse the empty
   one, and skips the step WITHOUT failing the job -- so the dispatch
   that is supposed to fire a component's release workflow has never
   run once. Reworded, with a warning not to write that token in a
   comment again. (link/release.yml and this repo's release.yml carry
   the same bug in their bump-and-tag step; handled separately.)

3. linux-aarch64 is now a REQUIRED platform key, which was step 3 of
   PLAN.md §5.2 and was waiting on link publishing one. v1.1.1 does, so
   from here a dropped target reddens this job instead of vanishing
   from every bundle.

The published bundles are materialized into a worktree at `published/`,
so the ".2 suffix" scan and the idempotence check read what is actually
published rather than a stale copy on main. The branch is created from
an empty-tree root commit on first use, so it carries no history that
has nothing to do with the compat matrix; it has been seeded already
with bundle 2026.08.04, because every bundle is kept forever and the
move must not lose the one that exists.

bundles/*.json is deleted from main -- it is now a stale copy of data
that lives elsewhere, and a wrong "current" is worse than none. The
README stays and documents the branch.

Verified by running the whole job in a container against a bare repo
standing in for the remote: first run creates the branch and publishes
both files with all three asset keys, second and third runs report
"identical to the published current.json -- nothing to publish" and
push nothing, and the stale check now runs and reports both components
as having nothing releasable.

Co-Authored-By: Claude <noreply@anthropic.com>

bundles/README.md

@@ -13,7 +13,10 @@ nightly, so a missed dispatch self-heals. A run that finds nothing changed write
 
 See `docs/installer/PLAN.md` §7 for the design.
 
-## Layout
+## Where they live: the `bundles` branch
+
+**The JSON documents are not in this directory.** They are published to a branch of their own,
+[`bundles`](https://gitea.whitlocktech.com/RunicGateway/installer/src/branch/bundles), at its root:
 
 | File | What it is |
 |---|---|
@@ -24,14 +27,24 @@ Tags are UTC dates — `2026.08.04`. A second bundle on the same day (a sidecar
 morning, an overlay release in the afternoon) becomes `2026.08.04.2`, so one tag always names
 exactly one matrix.
 
+**Why a branch rather than `main`.** `main` is protected and this job is unattended: the pre-receive
+hook declines a push from CI, which is not something a nightly cron can resolve. A branch of its own
+keeps everything the original choice was for — a reviewable diff, a git history of the compat
+matrix, plain anonymous raw URLs, no credentials on the shard host — and needs no protection
+exception. Whitelisting a scheduled job for pushes to the default branch would buy nothing this does
+not.
+
+This directory keeps the documentation, because that is what belongs on `main`: the branch carries
+data, and only data.
+
 ## How the installer fetches these
 
 Plain anonymous `GET`s against a public repo. The shard host gets no git and no Gitea credentials
 (`PLAN.md` §1), so nothing here may require auth:
 
 ```
-https://gitea.whitlocktech.com/RunicGateway/installer/raw/branch/main/bundles/current.json
-https://gitea.whitlocktech.com/RunicGateway/installer/raw/branch/main/bundles/bundle-2026.08.04.json
+https://gitea.whitlocktech.com/RunicGateway/installer/raw/branch/bundles/current.json
+https://gitea.whitlocktech.com/RunicGateway/installer/raw/branch/bundles/bundle-2026.08.04.json
 ```
 
 Bundles are committed rather than published as Gitea releases because this repo's *own* releases are
@@ -58,9 +71,8 @@ protocol) or to either component's release version. All three move independently
     "protocol": 3,
     "assets": {                        // per-platform: the installer runs on each
       "linux-x86_64":   { "name": "…", "url": "…", "sha256": "…" },
+      "linux-aarch64":  { "name": "…", "url": "…", "sha256": "…" },
       "windows-x86_64": { "name": "…", "url": "…", "sha256": "…" }
-      // "linux-aarch64" joins these from link's first release built for it;
-      // bundle.yml already knows the name (PLAN.md §5.2)
     }
   },