fix: let prerelease builds follow their own channel

[thymikee]

Summary

Prepares prerelease builds for the nightly channel in #3380:

• Update notice: a -nightly. build checks and recommends agent-device@nightly, not @latest. The update-check cache records which dist-tag it read from, so a version cached from the other channel is never shown. After a channel switch the next command runs a fresh check, and a failed check still records the new channel.
• Android helper versionCode: a prerelease helper takes its base release's versionCode instead of 1, so a nightly or -dev helper replaces an older release. An equal code reinstalls when the checksums differ.

3 files.

Validation

At cdf4e654b7:

• src/__tests__/update-check.test.ts: 8/8 pass, including the channel-switch and failed-check cases.
• Live Android run on an API 37 emulator (evidence):
  • The published 0.21.24 helper was outdated and got replaced; the device then reported versionCode=21025.
  • The next run reported current and did not reinstall.
  • A nightly helper with the same code reinstalled once (mismatched), then reported current.

[github-actions]

Size Report

Metric	Base	Current	Diff
Installed (including dependencies)	5.16 MB	5.16 MB	+309 B
Package (unpacked)	5.16 MB	5.16 MB	+309 B
Package (download)	1.55 MB	1.55 MB	+100 B

Startup median (7 runs, lower is better):

Scenario	Base	Current	Diff
CLI --version	27.8 ms	27.8 ms	+0.0 ms
CLI --help	84.8 ms	89.1 ms	+4.3 ms

[thymikee]

The prerelease channel change is not ready to merge: nothing yet shows how the new helper versionCode behaves on a device, as reviewed at 652160e.

The change in scripts/build-android-helper.sh alters the versionCode stamped into every prerelease helper APK. A -dev or -nightly helper used to carry code 1, so the install decision in helper-package-install.ts always saw it as current. With the new code, an equal code reinstalls on a sha256 mismatch, and a lower installed code counts as outdated. No test or run exercises this route. The only coverage is a local awk run, and the PR says there was no live run. If adb install -r behaves differently with an equal or higher code, or if the manifest or packaged versionCode disagrees with what the device reports, nightly and -dev users could get a reinstall loop or a stale helper. Could you run this on an Android emulator at the PR head? Build a snapshot helper with a -dev or -nightly version over an installed helper that has the stable code. Please show three things. First, the versionCode: line from dumpsys package or pm list packages --show-versioncode, equal to the stamped value. Second, the install decision, with reason 'outdated' or 'mismatched' and installed:true. Third, a second run that reports reason 'current' with no reinstall.

Smoke Tests is still running, and I could not read its log, so I can't say which lane is red or whether it passes. The Android smoke route builds and installs the helper through that script with a -dev version, so it overlaps this change. I did not check the #3380 workflow, so I can't confirm that the 'nightly' dist-tag and the '-nightly..' version shape match what it will publish. There are no conflicts. Before merge, the live Android run above must show the stamped versionCode and both the replace and no-reinstall decisions.

[thymikee]

I ran the live Android check you asked for at da80ce53b4, the #3379 head after rebasing onto main (6eef69a). It used a Pixel_9_Pro_XL_API_37 emulator (API 37) on emulator-5556. Each run used a new AGENT_DEVICE_STATE_DIR, so a fresh daemon re-inspected the device instead of reading the in-memory install cache. The decisions below come from the android_snapshot_helper_install_decision diagnostic in each session's request log.

1. A -dev helper replaces a stable one. I installed the published agent-device@0.21.24 helper first (versionCode=21024). Then I ran pnpm package:android-snapshot-helper:npm at 0.21.25-dev, which stamped 21025 into the manifest, and then snapshot --platform android --serial emulator-5556:

{"versionCode":21025,"installedVersionCode":21024,"installed":true,"reason":"outdated"}
dumpsys: versionCode=21025  versionName=0.21.25-dev

2. A second run doesn't reinstall. New daemon, same APK:

{"versionCode":21025,"installedVersionCode":21025,"installedSha256":"2bdf98…","artifactSha256":"2bdf98…","installed":false,"reason":"current"}

3. An equal code reinstalls on a checksum change, once. I set the version to 0.21.25-nightly.20261011.1 only for this check and did not commit it. The rebuilt helper keeps 21025:

run 1: {"versionCode":21025,"installedVersionCode":21025,"installed":true,"reason":"mismatched","shaMatch":false}
run 2: {"versionCode":21025,"installedVersionCode":21025,"installed":false,"reason":"current","shaMatch":true}
dumpsys: versionCode=21025  versionName=0.21.25-nightly.20261011.1

adb install -r accepts an equal versionCode. The stamped manifest code matches what dumpsys reports, and there is no reinstall loop.

On #3380: it publishes the nightly dist-tag with versions shaped X.Y.Z-nightly.<YYYYMMDD>.<run> (scripts/release-version.mjs), which matches this PR's -nightly. check.

[cubic-dev-ai]

All reported issues were addressed across 3 files

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[thymikee]

This PR is ready. The 652160e findings are now fixed, and I found no new problems at b384e85.

The live emulator run now covers the helper route that builds with a -dev version, so the evidence ask from the earlier review is met. That run was on the pre-rebase head, and I did not re-run unit tests or the device run myself. I reviewed the PR's own 3-file patch, not the base movement from the rebase. I did not read scripts/release-version.mjs from #3380, so the nightly version shape rests on the issue text and your description.

Not blocking: the update-check cache in https://github.com/callstack/agent-device/blob/b384e85/src/cli/update-check.ts#L45 stores only latestVersion, so a user who switches between a nightly and a stable install inside the 14-day window could see one channel's version next to the other channel's install command. You can add distTag to the cache and gate the notice on it, or reply that the cache self-heals and resolve the thread. Either is fine.

The one open Cubic thread still applies as a low-priority note on the same cache: #3379 (comment). It matches the point above, so one reply can close both.

The 11 checks that are not green were all cancelled when newer runs replaced them, and none has a failed step. Please re-run them. Once they pass, nothing else stands in the way of merging.

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[thymikee]

The PR is ready from a code view. At cdf4e65 the cache now stores the channel, so a prerelease build keeps following its own channel. The two earlier cubic-dev-ai points are fixed. The notice and the install hint both key off the channel, and a failed check after a channel switch no longer repeats on every command.

Not blocking: the catch branch in https://github.com/callstack/agent-device/blob/cdf4e65/src/cli/update-check.ts#L81 has a three-line comment about why the channel is recorded, and the test 'a failed check after a channel switch records the new channel and drops the old version' already says it, so you can drop or shorten the comment or leave it.

Both open inline threads from the other reviewer do not apply any more, so please resolve them. The first is #3379 (comment), which is fixed because the cache stores distTag and the notice and install hint read it. The second is #3379 (comment), which is fixed because the failed-check branch and both success branches now write distTag, so the check stops once any check has finished.

Smoke Tests is still running and has not failed. This PR touches only src/cli/update-check.ts, its test and scripts/build-android-helper.sh, and smoke runs have the update notifier off, so I see no overlap. There are no conflicts.

I did not run the unit tests or any live device run on this commit. The device-facing helper route was checked on an earlier head and this change does not touch it. The large file count comes from the base rebase, and I reviewed only the three files of the PR's own patch. Once Smoke Tests goes green, the PR is ready for your merge decision.