Confirm a slim device is actually slim before it is ready

No files, tests, or entry points are named in the issue. First trace the device readiness and simlock doctor paths, then resolve the open questions before implementation; done means the listed completion conditions hold for slim, full, crash-recovery, and older-runtime cases without Android-specific core changes.

Request: #152

Problem

A slim device reports featureProfile: "reduced" as soon as the disable commands ran and the device rebooted. Nothing looks at the running device afterwards.

launchctl disable accepts a label the runtime does not have, so a daemon Apple renamed or removed is "disabled" with no effect. A slim device can be heavier than reported, and nobody is told. Operators who size capacity on slim devices lose memory they think they have. Anyone upgrading to a new iOS runtime cannot tell whether slim mode still works there.

Two facts are missing today:

• After the slim reboot: is every service Simlock meant to disable in fact not running?
• For an installed runtime: which labels in Simlock's disable list does that runtime not have?

Who it is for

• Operators who turn on ios.slim.enabled and plan capacity on the savings.
• Operators upgrading to a new iOS runtime.
• Agents and people who read featureProfile on a lease.

Outcome

• Before a slim device is reported ready, Simlock checks the running device against the set it meant to disable. Every lease path goes through readiness, so no lease is granted on an unchecked slim device.
• A device that passes is reported reduced, as today. The check adds no boot.
• A device that fails is slimmed and rebooted once more. If it still fails, the device is still ready and the lease is still granted. One event names the device and the services still running.
• simlock doctor reports, per installed iOS runtime, the labels in the disable list that the runtime does not have. It boots nothing to find out.
• The check, the event, and the doctor finding have one platform-neutral shape: platform, device, what was expected off, what was found on. A future Android slim mode (#151) reuses them without a core change.

Non-goals

• Failing a boot or a lease because the check failed. A failed or skipped slim never fails the lease.
• Re-enabling services, updating the label list, or otherwise fixing drift.
• Checking --full devices, crash-recovery reboots, or runtimes below iOS 18.5. Nothing was applied on them.
• Checking a device again after it is ready, or while it is leased.
• Measuring memory or process counts. The check is per service, not per byte.
• Android slim mode itself (#151).

Completion conditions

• With slim on, a device whose whole disable set is off after the slim reboot is granted with featureProfile: "reduced", and simlock events shows device.slimmed and no failure event for that boot.
• When a service in the disable set is still running after the slim reboot, Simlock applies the set and reboots once more before the device is ready.
• When a service is still running after that retry, the lease is granted, and simlock events shows exactly one event for that boot naming the device and every service still running.
• A check that passes on the first try adds no boot to the lease.
• With slim on, simlock doctor names each installed iOS runtime that lacks a label from the disable list, and the missing labels, without booting a device. With slim off it reports nothing.
• A --full lease, a crash-recovery reboot, and a boot on a runtime below iOS 18.5 produce no check, no retry, and no event.
• The event payload and the doctor finding carry the same fields for every platform, and nothing outside the iOS driver names launchd.

Open questions

1. After a failed retry, is the device reported reduced or full? Recommended: reduced. The services that did stop are gone, and a false full makes push or StoreKit fail with no explanation (ADR 0002 point 10 reasons the same way).
2. Does doctor report drift for a runtime no device has booted on yet? Recommended: yes. Drift is a property of the installed runtime and should be visible before the first lease.
3. Does a label the runtime does not have count as passing the readiness check? Recommended: yes. It cannot be running. It is drift, which doctor reports, not a failed check.
4. After a failed retry, does the next plain reboot of that device (idle shutdown, then boot, no erase) run the whole pass again, or trust the idempotence marker? Recommended: trust the marker. The event is the record, and a device that cannot converge would otherwise cost three boots on every boot.
5. When the first check fails and the retry passes, is that visible? Recommended: no separate event; device.slimmed says the pass took two attempts.

Written by an agent.