feat(ios): physical iOS 27 support - #538

…y target list

The preview / Argent Lens window streams frames over simulator-server, which
refuses physical iOS devices (kind === "device", driven over CoreDevice). With
the physical-ios-devices flag on, a connected iPhone leaked into
GET /preview/simulators because the iOS branch matched any platform === "ios"
without checking kind — surfacing a target the UI can't drive (and emitting an
entry with no runtime under a type that asserted runtime: string).

- Exclude physical iOS (kind === "device") from the preview list, mirroring the
  existing Chromium exclusion.
- Consume list-devices' own exported ListDevicesResult type instead of a
  hand-rolled copy that had already drifted from it (the soundness hole tsc
  couldn't catch because invokeTool<T> takes a caller-supplied generic).
- Extract the mapping into a pure, exported devicesToPreviewEntries() and add
  regression tests asserting physical iOS + Chromium are excluded while the
  simulator and Android emulator are kept.

…app behavior

list-devices description and the simulator-server guard message listed
screenshot/gesture-tap/gesture-swipe/button but omitted launch-app, which
is implemented for physical iOS via devicectl. The README limitations list
omitted restart-app, which (like open-url/reinstall-app) returns a clear
"not supported" error on physical iOS.

…ice-support

# Conflicts:
#	packages/tool-server/src/preview.ts
#	packages/tool-server/src/tools/open-url/platforms/ios.ts

…ice-support

…lity matrix

Review follow-ups on the physical-iOS CoreDevice feature:

- discovery: parsePhysicalIosDevices surfaced every host iOS simulator as a
  phantom physical device (devicectl lists simulators with transportType
  "sameMachine"); gate on the physical ECID UDID shape, which also aligns
  discovery with classifyDevice's routing. Verified against real devicectl JSON
  and a connected iPhone (returns only the device, not the host's simulators).
- run-sequence: was eagerly resolving simulator-server for a physical iPhone,
  failing the whole call before step 1; hold no eager service so per-step
  CoreDevice routing works.
- describe: swallowed the simulator-only guards and returned an empty tree with
  a misleading "reboot the simulator" hint; reject with a clear error instead.
- swipe: command timeout was a fixed 15s, killing long swipes mid-drag; scale
  the timeout with the requested duration and clamp degenerate durations
  (extracted swipeDragParams, unit-tested).
- native-profiler: guard the session blueprint so a physical iPhone isn't driven
  via simulator-only simctl (which mislabeled it an unresponsive "simulator").
- capability matrix: tools whose iOS backend is simulator-only (keyboard, paste,
  rotate, gesture-pinch/rotate/custom, screenshot-diff, native-devtools-*,
  native-profiler-start) now declare apple.device:false, so physical iOS is
  rejected with a clean 400 at the capability gate rather than a 500 from a deep
  service guard. open-url/reinstall-app/restart-app throw UnsupportedOperationError.
- launch-app: wrap the devicectl launch so "app not installed/signed" surfaces a
  clean message instead of a raw subprocess blob.
- core-device: check the feature flag before the pymobiledevice3 setup probe;
  echo a custom tunneld port in the manual-fallback hint.
- docs: flags description and README now match the supported tool set and the
  auto-start prompt reality.

Verified end-to-end on a physical iPhone (iOS 27): discovery, tunnel
auto-escalation, screenshot (1179x2556), and swipe.

…e entry

The previous commit guarded the shared native-profiler-session blueprint
against physical iOS, but that blueprint also backs the device-agnostic
analysis tools (profiler-stack-query / profiler-combined-report / -analyze),
which profiler-query-android-capability.test.ts intentionally keeps supported
on Apple device. The guard made those analysis tools 500 on a physical-iOS
device_id.

Scope the fix to where the actual bug is: only native-profiler-start enumerates
running processes via simulator-only `simctl` (mislabeling a real iPhone as an
unresponsive "simulator"), and it already declares apple.device:false, so the
capability gate rejects it cleanly (400) before execute() runs. Drop the
redundant session-blueprint guard; the analysis tools keep their cross-device
capability. Also formats physical-ios-followups.test.ts.

launch-app drives a physical iPhone via `xcrun devicectl` directly rather than
the CoreDevice service, so its handler never hit the flag check that gates every
other physical-iOS operation — with `physical-ios-devices` off, launch-app on a
physical UDID still launched the app. Extract the gate into a shared
assertPhysicalIosEnabled() (reused by the CoreDevice factory and tunnel start)
and call it from the launch-app physical-iOS branch before shelling devicectl.

Add coverage: the launch-app flag gate, assertPhysicalIosEnabled, and the
gesture-swipe physical-iOS routing (coords + duration forwarding).

… as unsupported

The README limitations section listed only the interaction/lifecycle tools that
reject on physical iOS; align it with the actual behavior by also noting that
describe (accessibility), the native-* inspection tools, native-profiler-*, and
screenshot-diff are simulator-only.

…; cover pmd3 argv

On iOS 18-26 Apple gates host-driven input (the CoreDevice "remote control"
services behind tap/swipe/button) to iOS 27+, so the device is discovered and
advertised as tap-capable, then fails mid-session with a raw `CoreDeviceError
9021`. Detect that specific failure in `conciseError` (matched against
pymobiledevice3's stderr/stdout only, never the argv-echoing execFile message,
so a HID coordinate that contains "9021" can't false-positive) and surface an
actionable message that points at iOS 27 and notes screenshots still work.
`screen-capture` is not gated, so the screenshot path is untouched.

Also note the physical-iOS/CoreDevice routing in the gesture-tap and
gesture-swipe descriptions, and add a focused test that drives the CoreDevice
factory through a mocked execFile boundary to pin the exact pmd3 argv for tap,
button, screenshot, and swipe (previously untested — every other physical-iOS
test mocks the CoreDeviceApi wholesale) plus the 9021 translation.

… on button

…ice-support

# Conflicts:
#	packages/tool-server/src/preview.ts

…quivalent

button's services() resolved coreDeviceRef() unconditionally for any
physical-iOS button press, before execute() validates whether the
button is even supported. Since the registry resolves services()
before execute(), pressing appSwitch/actionButton on a physical
iPhone triggered CoreDevice's tunnel-setup side effects (possibly a
macOS admin prompt) just to reject the button afterward. Skip
resolving the service when the button has no CoreDevice HID mapping.

…essage accuracy

core-device.ts threw plain Error at all 12 sites, and ax-service.ts /
simulator-server.ts's own new physical-iOS rejection branches did too
- unlike every sibling blueprint, which uses FailureError with a
dedicated error_code. Every physical-iOS failure (auth declined, no
tunnel, missing pymobiledevice3, iOS<27 gate, flag disabled) was
landing in telemetry as generic REGISTRY_TOOL_FAILURE_UNCLASSIFIED,
indistinguishable from any other crash. Add CORE_DEVICE_* /
AX_PHYSICAL_DEVICE_UNSUPPORTED / SIMULATOR_SERVER_PHYSICAL_DEVICE_UNSUPPORTED
failure codes and convert every throw site.

Also, three smaller correctness fixes found in the same pass:
- resolveTunnel's `tunnel-port == null` check let a port of 0 through
  as "present", inconsistent with the sibling tunnel-address check
  which treats any falsy value as missing.
- The iOS<27 gate message claimed "tap/swipe/button" all require
  iOS 27+, but this is hardware-verified false: screenshot and
  hardware buttons work below iOS 27, only touch (tap/swipe) is
  actually gated.
- conciseError's line-matching heuristic could pick a misleading
  rich-boxed Python source-context line (e.g. "if rsd is not None:")
  instead of the real exception (e.g. "OSError: No route to host")
  from a stale-tunnel traceback, and searched execFile's synthesized
  "Command failed: <argv>" message with equal priority to the real
  stderr/stdout output.

… too

native-profiler-start already rejects physical iOS (apple.device:false)
since live capture uses simctl process enumeration that mislabels a
real iPhone as a simulator. stop/analyze were left at device:true, so
- since a session can never exist for physical iOS - they always fell
through to a generic "no active session" error instead of the same
clean, actionable rejection. Also fixes the README's "native-profiler-*"
claim, which the stop/analyze gap made inaccurate, and two other
accuracy issues found in the same pass: the iOS<27 limitation
overstated to include hardware buttons, and a note that launch-app
(devicectl) doesn't need the CoreDevice tunnel other tools require.

# Conflicts:
#	packages/argent/scripts/bundle-tools.cjs
#	packages/native-devtools-ios/src/index.ts
#	packages/tool-server/src/blueprints/native-devtools.ts
#	packages/tool-server/src/blueprints/simulator-server.ts
#	packages/tool-server/src/tools/describe/platforms/ios/index.ts
#	packages/tool-server/src/tools/devices/boot-device.ts
#	packages/tool-server/src/tools/devices/list-devices.ts
#	packages/tool-server/src/tools/gesture-custom/index.ts
#	packages/tool-server/src/tools/gesture-pinch/index.ts
#	packages/tool-server/src/tools/gesture-rotate/index.ts
#	packages/tool-server/src/tools/keyboard/index.ts
#	packages/tool-server/src/tools/launch-app/index.ts
#	packages/tool-server/src/tools/launch-app/platforms/ios.ts
#	packages/tool-server/src/tools/native-devtools/native-describe-screen.ts
#	packages/tool-server/src/tools/native-devtools/native-devtools-status.ts
#	packages/tool-server/src/tools/native-devtools/native-find-views.ts
#	packages/tool-server/src/tools/native-devtools/native-full-hierarchy.ts
#	packages/tool-server/src/tools/native-devtools/native-network-logs.ts
#	packages/tool-server/src/tools/native-devtools/native-user-interactable-view-at-point.ts
#	packages/tool-server/src/tools/native-devtools/native-view-at-point.ts
#	packages/tool-server/src/tools/paste/index.ts
#	packages/tool-server/src/tools/restart-app/index.ts
#	packages/tool-server/src/tools/restart-app/platforms/ios.ts
#	packages/tool-server/src/tools/rotate/index.ts
#	packages/tool-server/src/tools/run-sequence/index.ts
#	packages/tool-server/src/tools/screenshot/index.ts
#	packages/tool-server/src/utils/device-info.ts
#	packages/tool-server/src/utils/ios-devices.ts
#	scripts/download-native-binaries.sh

# Conflicts:
#	packages/tool-server/src/preview.ts

…ren't blocked

…ice-support

The app-free CoreDevice accessibility path was investigated on a physical
iPhone (iOS 27). The on-device accessibility tree is served by CoreDevice's
axAuditDaemon, but Apple gates it: the DTX service
`com.apple.accessibility.axAuditDaemon.remoteserver.shim.remote` requires the
`com.apple.mobile.lockdown.remote.trusted` entitlement — over the developer
(untrusted) CoreDevice tunnel pymobiledevice3 forms, the daemon accepts the
socket but terminates it on the first request (every audit selector, and even
the standard DTX capability handshake). The RemoteXPC replacement
`…axAuditDaemon.remoteAXService` requires `AppleInternal`, unreachable by any
third party. DTX transport itself works over the same tunnel
(`developer dvt proclist` succeeds), so this is Apple's auth wall, not a
transport gap. Screenshot (`canViewDeviceDisplay`) remains the only app-free
screen capture.

Replace the imprecise describe rejection ("no on-device accessibility/describe
path") and the ax-service backstop's "not supported yet" with accurate,
evidence-based messages, and split describe out of the README "not yet" list.

Drive a physical iPhone through one long-lived pymobiledevice3 process per
device instead of spawning the CLI per interaction. Each `pymobiledevice3`
invocation cost ~0.8s (~0.5s just `import pymobiledevice3`); the sidecar
connects the RSD tunnel and opens the HID/screenshot services once, so a
warm tap/button/swipe is now ~150-320ms (5x) — verified live on an iPhone 15
(iOS 27) through the tool-server. The agent is a small Python program,
base64-embedded in coredevice-agent.ts (survives esbuild, no build-pipeline
wiring), materialized to a temp file and run with pmd3's own venv interpreter;
it speaks newline-delimited JSON over stdio. core-device.ts now maps its
responses (incl. the iOS-27 9021 gate) to FailureErrors and tears the process
down on dispose.

Also make `describe` work on a physical iPhone: it returns the SpringBoard
home-screen layout (app icons + dock) via CoreDevice's springboardservices —
the only app-free structured screen data on a real device. Icon frames are
derived from the home-screen grid (row-major first-fit so multi-cell widgets
don't shift the icons after them) and are approximate; the hint says to
confirm with screenshot and that in-app content isn't reachable. Verified the
describe→tap loop live (tapped Settings via describe's frame; it opened).

In-app accessibility stays Apple-gated: the axAuditDaemon DTX service drops
the connection on the first message over the developer tunnel, and its RemoteXPC
replacement needs the AppleInternal entitlement.

Replaces the per-call argv test with sidecar/adapter/agent-protocol coverage.

Replaces the SpringBoard home-screen-only describe with the device's live
on-screen accessibility tree, read app-free over CoreDevice via the iOS-26+
axAudit service. Works in ANY app and on the home screen (the same VoiceOver
walk): labels, values, traits (mapped to roles) and reading order are exact.

The unlock is the RSDCheckin handshake iOS 26 added to RSD DTX services. pmd3's
DtxServiceProvider opens RSD services with a raw connect and skips RSDCheckin,
so iOS 26/27 dropped the accessibility daemon on the first byte (which had read
as an "Apple wall"); the sidecar monkeypatches the open to go through
start_lockdown_service, which performs the checkin. Verified live on iPhone/iOS
27: describe Settings -> read the "Other…" button's frame -> gesture-tap it ->
the Join-Wi-Fi form opened. Home screen lists every app + widget.

Frames: Apple exposes no per-element geometry on hardware, so exact rects come
only from the accessibility audit (a subset of elements, correlated to the tree
by element id); the rest are interpolated from reading-order neighbours -
enough to tap a list row, with a hint to confirm precise taps via screenshot.
Pixel-exact in-app frames would need an on-device XCUITest runner (code-signing).

- sidecar: RSDCheckin fix + an `axtree` op (iter_elements walk + run_audit rects
  + screen size), replacing `homescreen`.
- new ios-coredevice-ax-adapter (caption->role/label parse, rect normalize,
  frame interpolation); removes the springboard adapter. Source: coredevice-ax.

…ice-support

…ice-support

…ice-support

…ice-support

Conflict in gesture-swipe: main (#429) added the `settle` momentum-free swipe
while this branch added CoreDevice routing for physical iPhones.

The two features can't simply coexist. `settle` is built from an eased train of
individual touch events sent to the simulator-server; CoreDevice instead performs
one pymobiledevice3 HID drag whose trajectory is a fixed linear interpolation
over (steps, duration), so the per-sample easing cannot be expressed through it.
Silently dropping the flag would return a flinging swipe while the caller believes
it scrolled a deterministic distance.

So: keep main's ease-out for simulators/emulators, keep CoreDevice routing for
physical iOS, and reject settle:true on a physical iPhone with an
UnsupportedOperationError (400) — the same way `button` rejects buttons with no
HID equivalent. As there, services() skips resolving CoreDevice for a swipe that
is going to be rejected, so it doesn't pay for tunnel setup first. Tool and schema
descriptions now state the limitation instead of implying settle works everywhere.

…ice-support

Conflict in packages/registry/src/failure-codes.ts: both sides appended to
FAILURE_CODES. Resolved as the union - main's IOS_SETTINGS_PERMISSION_FAILED /
SETTINGS_PERMISSION_UNSUPPORTED (#462) alongside this branch's CORE_DEVICE_* block.

- op_axtree: bound the audit completion wait at 10s. The event may never
  arrive (locked device, unsupported audit) and an unbounded queue get()
  wedged the strictly-serial agent forever, timing out every later op.
- CoreDeviceAgent.start(): attach a spawn 'error' handler — without one a
  spawn-layer failure (EACCES/EMFILE) is an unhandled 'error' event that
  takes down the whole tool-server — and reject the ready handshake from
  the exit/error handlers so an agent that dies at spawn fails fast
  instead of eating the full 30s timeout.
- materializeAgentScript: never execute a pre-existing tmp file without
  verifying its content (predictable shared-/tmp path was plantable by
  any local user on Linux); fall back to a private path on mismatch.
- resolvePmd3Python: reject launcher shebangs (#!/usr/bin/env python3
  'resolved' to env itself, which then treats the agent script as the
  command to exec).
- Regenerate AGENT_SCRIPT_B64 from the .py, fix the stale source-of-truth
  comment, and pin the pair with a sync test.

…ice-support

…ice-support

# Conflicts:
#	packages/tool-server/src/utils/ios-devices.ts

A sweep at the new head found eighteen more behaviours green when broken.
The consequential ones are now pinned, each against the mutation that
exposed it:

- httpAxTree's `/api/ax-tree` path was asserted by nothing: the fetch stubs
  ignore their arguments, so pointing describe's only wire path at a route
  the sim-server does not serve left the whole suite green.
- Two `platform === "ios" && kind === "device"` guards were exercised only
  with an iPhone udid, and a physical Android phone is `kind: "device"` too.
  Dropping the platform half of gesture-custom's second-touch check silently
  takes two-contact gestures away from Android, and of await-screen-idle's
  `rotatingRead` gives Android the order-blind signature and the CoreDevice
  element ceiling. Both now have an Android control.
- The physical-UDID shape had none of its three load-bearing properties held:
  the anchors, the exact 8/16 hex runs, and case-insensitivity. The existing
  negatives fail an unanchored, loosely-quantised, uppercase-only pattern too.
- open-url's leading `^` is what makes a value starting with `-` fatal, and
  every rejected fixture lacked a colon, so the unanchored pattern rejected
  them as well.
- native-devtools' physical-iPhone backstop, while its identical ax-service
  twin was covered; and the simulator-server factory's narrowing that keeps
  the tvOS probe and the automation toggle off hardware.
- In the CoreDevice adapter: the two non-Button value-bearing roles, the
  declared trait precedence, approxFrame's clamp, and the interpolation
  denominator that puts a rect-less element inside its gap rather than
  spread across the whole list.
- coreDeviceAxTreeSchema's `rect` (the one remaining field the adapter calls
  a string method on) and `screen.h`.

Also drops `.finite()` from the schema's screen dimensions: zod 4's
`z.number()` already rejects NaN and both infinities, so it refined nothing
— which is why no mutation of it could fail.

…limit

The truncation guard refused on any full read, but a full read only means
"at least this many": a screen of exactly PHYSICAL_IOS_AX_LIMIT elements is
indistinguishable from a larger one on any single poll, and it settles
correctly, because its window IS the whole set. Re-running the sliding-window
reproduction across the boundary showed the regression - 120 elements settled
in 3 polls before the guard and refused after it.

Record that a read came back full and consult it only once the wait has
already failed, so the note explains a `settled: false` that was going to
happen anyway and never causes one. Verified across the boundary: 50, 119 and
120 settle in 3 polls with no note; 121 and 200 answer false with it.

…t have seen

A CoreDevice read returns at most 120 elements, one step further along the
VoiceOver walk each time, so on a longer screen a no-match means "outside
this window", not "gone" - describeIos says so itself on such reads ("a
'not found' here is not proof of absence"). `hidden` is the one condition a
zero-match read satisfies, so it returned success:true on the first poll for
an element that was on screen, and the caller acts on the element being
gone. Reproduced with a 200-element screen whose target sits 30 rows past
the window: hidden answered true in 1ms while `exists` found the same
element once the window reached it.

A no-match on a full read no longer satisfies `hidden` - the wait keeps
polling and, if it runs out, says why. The positive conditions are untouched:
a truncated read can delay a match, never invent one.

Also, three agent-facing docs still stated rules this feature falsified - the
udid-shape dispatch table, the "filter for platform: ios" simulator-setup
step (which now selects a connected iPhone, since it ranks ready ahead of a
shut-down simulator), and the rule's per-platform readiness list - and
propose_variant's udid description offered the preview a target the preview
whitelist drops.

Widening the ios-describe import into await-ui-element broke five test files
whose `vi.mock` of that module listed only `describeIos`; they now spread the
original, so the next export added there does not break them again.

…-simserver

# Conflicts:
#	packages/tool-server/src/blueprints/simulator-server.ts
#	packages/tool-server/src/tools/devices/boot-device.ts
#	packages/tool-server/src/tools/reinstall-app/platforms/ios.ts
#	packages/tool-server/src/utils/device-shutdown.ts
#	packages/tool-server/src/utils/ios-devices.ts

…iPhone"

This reverts commits 7a1be55 and fd0bd3a.

The premise was that the `mainTouchscreen` report's contact-id byte gives a
physical iPhone two fingers. It does not. The byte is an identifier and the
device accepts reports addressed to different ids, but iOS reads one finger
off them regardless. Re-measured on an iPhone 15 / iOS 27 against an iOS
18.6 simulator receiving byte-identical input, on Apple Maps:

| gesture                      | simulator          | iPhone                      |
| ---------------------------- | ------------------ | --------------------------- |
| two-finger tap               | zooms out one step | nothing                     |
| two-finger vertical drag     | enters 3D          | pans                        |
| symmetric pinch 0.35 -> 0.05 | zooms out          | pans by one contact's delta |
| two-finger hold 600ms        | nothing            | drops a pin (a long press)  |

The pin is the clearest of the four: a long press only fires for a single
finger, so during a two-contact hold the device had one finger on the glass.
The pinch is the most quantitative: the map translated by exactly one
contact's displacement at unchanged zoom.

The original measurement read a pan of that kind as a zoom. A pinch that far
apart moves the map a long way, which looks like something happened.

So `gesture-pinch` and `gesture-rotate` go back to `apple.device: false` and
`gesture-custom` rejects its two-point form on hardware again — a shipped
`pinched: true` over a screen that only panned is the outcome worth
avoiding. Needs radon a7f4470b, which reverts the sim-server half.

…tions

settings-permissions: name what was actually checked - devicectl carries no
privacy verb in its command tree, and the configuration-profile route needs a
CMS-signed profile, so it folds into the signing requirement.

paste: drop it. The claim that its capability gate is what stops a paste from
silently going nowhere was wrong - the tool is not in setup-registry.ts on any
platform, so the gate never runs and nothing can call it. It is not a
physical-iPhone limitation.

…gated

The stated reason - that xctrace can only enumerate processes it is entitled
to profile, leaving nothing to attach to - does not hold. On a host with zero
codesigning identities, `xctrace record --device <ecid> --attach <pid>` against
a tethered iPhone 15 on iOS 27 produced a 37MB Time Profiler trace of
SpringBoard with symbolicated user-space frames.

The gate is right, but for the reason the capability comment already gives:
the iOS capture path resolves its target through `simctl spawn` and
`simctl listapps`, which are simulator-only. That is an unimplemented device
path, not a platform wall, and the README should not claim otherwise.

…hat was measured

xctrace: the device-profiling note read as unconditional. It was measured on
Xcode 16.4, and native-profiler's own iOS capture path documents a --device
recording-start deadlock for Xcode 26.4 and later, so an unqualified claim
points a reader on a newer Xcode at a known bug. Name the version, and record
that attach works by pid but not by name.

Frames: "Apple exposes no per-element geometry app-free on a physical device"
asserts more than has been established - #702 found no frame attribute in the
published inspector set, but the hit-test selector's encoding is unresolved and
the audit path does carry ElementRectValue_v1. Say what the read carries.

Both the README and the describe hint an agent reads on every physical-iOS
call said the audit reports no accessibilityIdentifier. It does report them:
_AXHierarchyElementsAttribute carries AccessibilityIdentifier_v1 with real
values, and the read simply does not parse them (#702). An agent told the
platform withholds identifiers stops looking; one told this read does not
surface them knows the selector is unavailable today without inferring a limit
that is not there. Behaviour is unchanged - an identifier selector still
matches nothing.

Same correction to the hint's frames clause: the read carries no geometry,
which is what was measured, rather than the device exposing none.

…eometry comments

Three comments said Apple exposes no per-element geometry app-free on hardware.
What was established is narrower: the inspector this read goes through publishes
no frame attribute. The hit-test selector's argument encoding is unresolved and
the audit path does carry ElementRectValue_v1 (#702), so the broader claim would
tell the next reader the question is closed when it is open.

No behaviour change - frames stay synthesised and the wire contract's rect stays
unsent.

Neither interface is imported anywhere: list-devices declares its own IosDevice
now that a physical entry carries kind and productType, so exporting these only
widened the surface knip's dead-code ceiling counts.

…-simserver

Two conflicts, both where main edited lines this branch had also touched:

- boot-device.ts: main moved the headless-boot helpers into
  utils/no-window-env.ts (androidHeadlessFromEnv / iosHeadlessFromEnv) in the
  same import block this branch extended with isPhysicalIosUdid and
  simulatorServerRef. Kept both sides. The physical-iPhone branch in bootIos
  returns before the Simulator.app GUI attach, so iosHeadlessFromEnv is never
  consulted for a hardware udid.

- describe/platforms/ios/index.ts: main reworded the comment above
  NON_INJECTABLE_HINT ("can never load argent's injected dylib" -> "cannot be
  relied on to load argent's dylib", matching #560's measured verdict) where
  this branch had inserted the physical-iOS hint constants directly above it.
  Kept the new constants and took main's wording.

…-simserver

# Conflicts:
#	packages/tool-server/src/blueprints/ax-service.ts
#	packages/tool-server/src/blueprints/simulator-server.ts
#	packages/tool-server/src/preview.ts
#	packages/tool-server/src/tools/await-screen-idle/index.ts
#	packages/tool-server/src/tools/await-ui-element/index.ts
#	packages/tool-server/src/tools/describe/contract.ts
#	packages/tool-server/src/tools/describe/platforms/ios/index.ts
#	packages/tool-server/src/tools/devices/list-devices.ts
#	packages/tool-server/src/tools/paste/index.ts
#	packages/tool-server/src/tools/profiler/combined/profiler-combined-report.ts
#	packages/tool-server/src/tools/profiler/query/profiler-stack-query.ts
#	packages/tool-server/src/tools/run-sequence/index.ts
#	packages/tool-server/src/tools/screenshot/index.ts
#	packages/tool-server/src/utils/device-info.ts
#	packages/tool-server/src/utils/device-shutdown.ts
#	packages/tool-server/src/utils/ios-devices.ts
#	packages/tool-server/src/utils/simulator-client.ts

- list-devices: keep the promised deviceSet tag on iOS simulator entries
- simulator-server: classify spawn failures on 'close', not 'exit', so
  stderr delivered after exit is not lost to the race
- skills/rules/argent.md: carve the physical-iPhone screenshot-first
  workflow out of the tapping rule that banned it
- await-screen-idle test: make the Android control fail when the
  rotatingRead platform narrowing is dropped
- followups test: add settings-permissions to the pinned simulator-only
  set and defer exhaustiveness to the registry-derived sweep
- paste: correct the apple.device rationale and the sweep's note about
  why paste is defined outside createRegistry