Android lane is not wired into pipeline.yml — releases still ship Windows-only (0.1.23 regressed a day after #174)

[dfattal]

#174 is closed and the Android lane works — but it is not wired into the release
path, so releases keep coming out Windows-only.

Evidence, one day later:

release	assets
preview-0.1.22	Setup .exe + android .apk ← APK attached by hand
preview-0.1.23	Setup .exe only

0.1.23 is now Latest, and displayxr-runtime/versions.json[browser] points at it.
So the gap #174 described reopened within hours of being closed.

Why

pipeline.yml builds Windows, signs, stages and promotes. release.sh grew N-asset
support in #175 and is verified for .apk publishing — but nothing in the pipeline
calls build-box-android.yml, and nothing hands release.sh an APK. The Android
lane is currently only reachable by workflow_dispatch, and the artifact has to be
downloaded and attached manually (which is what happened for 0.1.22).

So "Android is in the release train" is true of the tooling and false of the
automation.

What closing this looks like

• pipeline.yml calls build-box-android.yml (it is already workflow_call-able,
  with chromium_tag / patch_ref / job inputs) as a sibling of the Windows build.
• Both artifacts are collected before the release step, and the APK is passed to
  release.sh alongside the .exe — the N-asset path already handles the notes,
  the per-asset signature reporting and the Windows-only feed correctly.
• The two builds are on different boxes with different concurrency groups, so they
  can run in parallel; wall-clock is the slower of the two, not the sum.

Worth deciding at the same time

Whether an Android build should gate a release or merely ride along. If the
Android lane fails, should the Windows release still go out? Riding along is the
cheaper default and matches the current feed (which is Windows-only by schema), but
it means Android can silently fall behind again — exactly the failure this issue is
about. A loud warning on the release when the APK is absent would be the minimum.

Meanwhile

scripts/install-android-bundle.sh in displayxr-runtime already tolerates this: when
the pinned browser tag carries no APK it falls back to the newest release that does,
and prints that it did. So --with-browser still works today — it just installs
0.1.22's browser against a 0.1.23 pin.