doctor reports a devices.xml profile that a library profile hides

Read src/drivers/android/device-profile-source.ts and the driver wiring in src/drivers/android/index.ts; inspect the device profile source tests and AndroidDriver.advisories() seam in src/drivers/android/index.test.ts. Then run the focused Android driver tests and the CLI doctor tests in src/cli/index.test.ts. Done when hidden user profiles produce the specified advisories in order, existing physical advisories remain, no avdmanager process is started, and docs/CLI.md describes the advisory.

Part of #485.

Scope

simlock doctor tells an operator when a profile they made in Android Studio is not used because a Simlock library profile has the same name. After this PR, a hidden custom profile is visible instead of silently ignored.

In short

A library name always wins. When devices.xml defines a profile whose name a library profile answers to, doctor reports it as an advisory. A name the library shares with the SDK is not reported: the two agree.

flowchart LR
  X[devices.xml names] --> C{a library profile<br/>answers to it?}:::changed
  C -- yes --> W[doctor: device-profile-hidden]:::changed
  C -- no --> N[nothing]
  classDef changed stroke-width:3px

$ simlock doctor
Warning [android] device-profile-hidden: "Pixel 9" in devices.xml is not used: Simlock's own Pixel 9 profile answers to that name

devices.xml defines	Library has	Today	After
"Pixel 9"	Pixel 9	nothing reported	one advisory, naming "Pixel 9" and Pixel 9
"pixel_9"	Pixel 9 (other name pixel_9)	nothing reported	one advisory, naming "pixel_9" and Pixel 9
"PIXEL 9"	Pixel 9	nothing reported	one advisory, naming "PIXEL 9" and Pixel 9
"Pixel 9" and "Pixel 8"	both	nothing reported	two advisories, in devices.xml order
"My Tablet"	no such name	nothing reported	nothing reported
no file, or an unreadable one	—	nothing reported	nothing reported

If this goes wrong, doctor misses a hidden profile or reports one that is in use.

Technical spec

Modules touched

flowchart LR
  DOC[core Doctor] --> ADV[AndroidDriver.advisories]:::changed
  ADV --> PH[PhysicalHandler.advisories]
  ADV --> REG[DeviceProfileRegistry.hiddenUserProfiles]:::changed
  REG --> L[library source]
  REG --> U[UserDeviceProfileSource]
  classDef changed stroke-width:3px

• src/drivers/android/device-profile-source.ts: a new exported function hiddenUserProfiles(library, user) takes the library source and the UserDeviceProfileSource as two arguments. It reads only those two (static data and a file read), never BuiltinDeviceProfileSource, so it starts no process, cannot hang on avdmanager, and counts each devices.xml profile once although avdmanager lists it too. Neither source throws (the user source turns every read or parse failure into no profiles), so the function cannot reject. It returns, in devices.xml order, each devices.xml profile one of whose names a library profile answers to, ignoring case, paired with that library profile; the match is matchProfile over the library's profiles.
• src/drivers/android/index.ts: defaultDeviceProfileSources returns its three sources by name as well as in order, and the driver keeps the library and user ones. advisories() returns the physical handler's advisories followed by one { code: "device-profile-hidden", message } per hidden profile. The message is "<devices.xml name>" in devices.xml is not used: Simlock's own <library name> profile answers to that name. A driver built with an injected deviceProfileSources list (tests only) reports no hidden profiles.

Contract and event changes

None. DriverAdvisory.code is a free string the core does not interpret; the CLI prints it as Warning [android] device-profile-hidden: <message>.

Other code on the same state

• PhysicalHandler.advisories() (src/drivers/android/physical-handler.ts): its advisories are kept and come first.
• Doctor (src/core/doctor.ts) shows every driver advisory as a driver-advisory finding and never acts on one; --fix does nothing for it. advisories() also runs in the daemon's startup reconcile; with no process started, it adds only a file read there.
• UserDeviceProfileSource: an absent or unreadable devices.xml gives no profiles, so nothing is reported for it.
• BuiltinDeviceProfileSource: lists the same devices.xml profiles with OEM : User; not read here.

Rules in play

• safety.md: doctor reads devices.xml and changes nothing.
• architecture.md: the name match is matchProfile, not a second one; the check is bounded because it starts no process.

Tests

Seam: AndroidDriver.advisories() through createDriver in src/drivers/android/index.test.ts, with writeDevicesXml (model on "device-profile sources").

• reports device-profile-hidden for a devices.xml profile named like a library profile, with the message naming both
• reports one matching a library profile's other name, in any letter case, naming the library profile's display name
• reports two hidden profiles as two advisories, in devices.xml order
• reports nothing for a devices.xml profile no library profile answers to
• reports nothing for a library name the SDK also lists
• reports one advisory per profile when avdmanager list device also lists it with OEM : User, and runs no avdmanager
• reports nothing when devices.xml is missing or unreadable
• keeps the physical handler's advisories, before the new ones
• in the CLI tests (src/cli/index.test.ts): simlock doctor prints a driver-advisory finding to stderr as Warning [<platform>] <code>: <message>
• reports no hidden profiles for a driver built with injected deviceProfileSources

Done when

• With a devices.xml profile named "Pixel 9", advisories() returns one device-profile-hidden advisory naming it. simlock doctor shows driver advisories through the existing writeDriverAdvisoryWarnings (src/cli/index.ts), and --fix never acts on one, as the existing "--fix never acts on a driver-advisory finding" test in src/core/doctor.test.ts proves.
• docs/CLI.md (simlock doctor) describes the device-profile-hidden advisory.

Out of scope

• Reporting SDK profiles the library hides.
• Reporting models with no fitting image.

Depends on

• #490

Approval

• Approved for delivery

Written by an agent.