A preview system image installed makes the newest runtime its codename, not the highest API level

What is wrong

A preview system image installed makes the newest runtime its codename, not the highest API level

Where this came from

Confirmed in the bug bounty sweep tracked on #648 (finding 4). The reproduction was reproduced independently by the orchestrating session, the proposed fix confirmed green against the surrounding suite, and the finding re-confirmed against current main.

Spec

Area: src/drivers/android/index.ts (runtime ranking: lease default, defaultRuntime)

Severity: wrong device booted, silently, on a real host configuration — this
reporting machine itself has android-Baklava in
~/Library/Android/sdk/system-images/ beside android-36, android-36.1 and
android-37.0. simlock lease --platform android with no --os boots an
API 35 preview instead of 37.0, and simlock catalog /
getCatalog().defaultRuntime tell every caller and the console that Baklava
is the newest installed runtime — so an agent that trusts the catalog to pick a
valid --os, the stated purpose of that command (docs/CLI.md:1594), is
pointed at the preview. Same for --image-tag without --os.

Kind: defect — four doc lines state what "newest" means; the ranking
disagrees with all four.

Problem

#installedImages records each image's level as the android-<x> folder
suffix (index.ts:1602 separately reads AndroidVersion.ApiLevel into
sourceApiLevel precisely because the folder name is not always the level).
For the preview folder, the recorded level is the string "Baklava".

installedApiLevels (index.ts:2260) sorts that list with compareApiLevels
(index.ts:2280): Number(left) - Number(right), falling back to
localeCompare when either side is not a number. "Baklava" vs "37.0" is
NaN, so the text branch wins and any letter-starting name sorts after
every number. resolveSpec then takes levels.at(-1) (:808) and
listCatalog takes runtimes.at(-1) (:1253, and :1673 for the
--image-tag path) — both hand out "Baklava" as the newest.

The lines this breaks:

docs/CLI.md:217    `--os` defaults to the newest runtime already installed
docs/CLI.md:311    without `--os` the lease gets the newest API level that has one
docs/CLI.md:1594   which installed runtime is the default (the newest)
docs/CLIENT.md:352 `defaultRuntime` is the newest installed runtime

Range requests are unaffected: src/contract/os-range.ts parses a non-numeric
version to NaN and refuses it, so the gateway never routes a range to the
preview. This is the no---os default path and the catalog's own words about
itself.

Root cause

src/drivers/android/index.ts:2280 — compareApiLevels ranks API levels by
Number(name) and falls back to left.localeCompare(right), so a name the SDK
stores as a codename always outranks a number. It knows nothing about
sourceApiLevel, which the same file reads 680 lines earlier precisely because
the folder name is not always the level. The ranking, not the identity, is what
is wrong: "Baklava" is a legitimate name to list and to lease explicitly — it
is only wrong as the newest.

image-fit.ts:85 (for (const candidate of [image.sourceApiLevel, image.apiLevel])) already applies the correct rule elsewhere in the same
module: this file's own convention, missed at one call site.

Evidence

Test file:  src/drivers/android/scratch-newest-image.test.ts
Test titles: gives a lease with no OS the highest API level installed, not the
             preview folder whose name sorts last
             names the highest API level installed as the catalog's default runtime
Command:    pnpm exec vitest run --project unit \
              src/drivers/android/scratch-newest-image.test.ts

AssertionError: expected 'Baklava' to be '37.0' // Object.is equality
Expected: "37.0"
Received: "Baklava"
 ❯ src/drivers/android/scratch-newest-image.test.ts:156:28   (resolveSpec)
 ❯ src/drivers/android/scratch-newest-image.test.ts:168:36   (defaultRuntime)

The fixture's source.properties is the verbatim content of the real
~/Library/Android/sdk/system-images/android-Baklava/google_apis/arm64-v8a/source.properties
on this machine (AndroidVersion.ApiLevel=35, AndroidVersion.CodeName=Baklava
— orchestrator confirmed the file exists with those values beside 36/36.1/37.0).

Honesty checks (the finder's, then the orchestrator's):

• Both failures are preceded by expect(catalog.runtimes).toContain("Baklava")
  and the same for modelRuntimes["Pixel 9"] — so the failure can only be about
  ranking: the preview really is a listed candidate, not an omission.
• Preview folder removed from the fixture: both tests pass — nothing else causes
  it.
• Fixture reversed (AndroidVersion.ApiLevel=38): both tests pass against the
  broken code while still asserting the preview is newest — so the tests do
  not merely prefer numbers over letters; they fail exactly because the recorded
  level is ignored.
• Orchestrator: fix applied → new tests green and index.test.ts green
  (274 passed | 1 skipped), including its existing android-Baklava test at
  :4877, which pins that the preview still pairs with Pixel 9 and is still
  named Baklava; then the full drivers module: 21 files, 1229 tests green;
  then the entire unit lane: 269 files, 7029 passed | 4 skipped. Source
  reverted, both assertions re-confirmed red.

Proposed fix

src/drivers/android/index.ts:2260 — rank by the level the SDK recorded, keep
the folder suffix as the name:

function installedApiLevels(images: readonly SystemImage[]): string[] {
  const rank = new Map(
    images.map((image) => [
      image.apiLevel,
      /^\d/.test(image.apiLevel) ? image.apiLevel : (image.sourceApiLevel ?? image.apiLevel),
    ]),
  );
  return [...new Set(images.map((image) => image.apiLevel))].sort(
    (left, right) =>
      compareApiLevels(rank.get(left) ?? left, rank.get(right) ?? right) ||
      left.localeCompare(right),
  );
}

Verified above. No doc change needed — the four doc lines already describe this
behaviour.

Alternatives rejected

• Store sourceApiLevel as the level itself — renames the runtime across the
  catalog, --os, images[].runtime and modelRuntimes, and breaks the
  existing pin at index.test.ts:4885 that the runtime is named Baklava.
• Pick the max with contract/os-range.ts's compareVersions — Baklava parses
  to NaN there and would sort as the oldest, and it repeats the ranking in
  three call sites instead of one.
• A table of known codenames — invents a list the SDK owns and rots at the next
  preview.

Risk

• compareCatalogImages (index.ts:2272) sorts images[].runtime with the same
  comparator, so catalog.images order shifts (the preview moves next to API
  35 — where it belongs). A reviewer should confirm no console or CLI snapshot
  pinned the old order; the orchestrator's full-unit-lane run says none did.
• Two previews side by side (Baklava, Baklava-2, same recorded level) keep a
  deterministic order via the localeCompare tiebreak.
• resolveSpec with an explicit --os Baklava still resolves — the fix changes
  only who is newest, never what is listable or leasable.

Written by an agent.

Written by an agent.