ci(bundle): recognize a linux-aarch64 link asset

Step 1 of PLAN.md §5.2's four, and it has to be first. Two rules in this
job are strict in opposite directions: an unrecognized link asset name
fails the run, and a missing REQUIRED platform key fails it too. So the
name must be taught before the release that carries it, and the key can
only be required after one exists -- requiring it first would fail every
bundle for as long as the gap lasts.

This is therefore the mapping only. linux-aarch64 is not in REQUIRED
yet; step 3 promotes it once a link release actually ships the binary,
after which a dropped target reddens CI instead of vanishing silently
from every bundle.

The compose step needed no change: it builds the asset map from the
platform TSV, so a third key costs it nothing.

Edited on `main` and deliberately not on `edge`. The compose job runs
from `main`, and leaving `edge`'s copy untouched means the eventual
cutover merge has nothing to conflict over.

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

.gitea/workflows/bundle.yml

@@ -173,13 +173,23 @@ jobs:
 
           # Map link's binaries onto platform keys. The pattern is asserted, not
           # assumed: an unrecognized asset name is a hard failure so that adding
-          # a target to link's release.yml (aarch64, macOS) surfaces here as a
+          # a target to link's release.yml (macOS, a Windows arm64) surfaces here
-          # red run, rather than being silently dropped from every bundle.
+          # as a red run, rather than being silently dropped from every bundle.
+          #
+          # linux-aarch64 is recognized here BEFORE link publishes one
+          # (PLAN.md §5.2, step 1 of 4). That order is forced by the two rules
+          # below being strict in opposite directions: an unknown name fails the
+          # run, and a missing REQUIRED key fails it too. So the name has to be
+          # taught before the release that carries it, and the key can only be
+          # required after — requiring it first would fail every bundle for as
+          # long as the gap lasts. Step 3 promotes it into REQUIRED once a link
+          # release actually ships the binary.
           : > work/link-platforms.tsv
           while IFS="$(printf '\t')" read -r NAME URL; do
             [ -n "$NAME" ] || continue
             case "$NAME" in
               *-linux-x86_64)       PLAT=linux-x86_64 ;;
+              *-linux-aarch64)      PLAT=linux-aarch64 ;;
               *-windows-x86_64.exe) PLAT=windows-x86_64 ;;
               *) fail "unrecognized link asset '${NAME}' — bundle.yml does not know what platform to file it under. Teach it this name or the bundle would silently omit the asset." ;;
             esac

bundles/README.md

@@ -56,9 +56,11 @@ protocol) or to either component's release version. All three move independently
     "tag": "v1.1.0",
     "version": "1.1.0",
     "protocol": 3,
-    "assets": {                        // per-platform: the installer runs on both
+    "assets": {                        // per-platform: the installer runs on each
       "linux-x86_64":   { "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)
     }
   },