iOS Simulator panel: screenshot crash-loops on macOS 27.0, inspect unavailable

# iOS Simulator panel: `screenshot` crash-loops on macOS 27.0, `inspect` unavailable

## Summary

On macOS 27.0 (build 26A428), the Claude Code iOS Simulator integration cannot
capture the screen. `attach`, `tap`, and `open_url` all succeed, but every
`screenshot` call fails with:

```
screenshot failed: Claude Code iOS Simulator is restarting after a crash. Try again in 1s. The simulator restarts itself; retry this call.
```

and `inspect` returns:

```
'inspect' is not available right now. Use 'screenshot' instead.
```

Because the same capture pipeline feeds the live panel, the panel never renders
the app — it stays on the "Attach a simulator so Claude can see your app"
placeholder, even though `attach` reports `Simulator panel opened for ...`.

## Environment

| | |
|---|---|
| Claude Code | 2.1.269 |
| macOS | 27.0 (build 26A428) — **pre-release** |
| Hardware | Mac mini (2024), Apple M4 Pro, 24 GB |
| Architecture | arm64 (Darwin 27.0.0) |
| Xcode | 26.6 (17F113), `xcode-select -p` = `/Applications/Xcode.app/Contents/Developer` |
| Also installed | `/Applications/Xcode-beta.app` |
| iOS runtimes | 26.5 (23F77), 27.0 (24A5380i) |

## Steps to reproduce

1. Boot any iOS simulator: `xcrun simctl boot `
2. `attach` to it via the Claude Code iOS Simulator tool — succeeds, returns
`Simulator panel opened for ... Coordinate space for tap/swipe: 440x956 points`
3. Call `screenshot` on that same device

**Expected:** a PNG of the simulator screen, and the panel renders the device.

**Actual:** the call fails with the "restarting after a crash" message, and the
panel continues to show the attach placeholder. Retrying reproduces it
indefinitely.

## What works vs what fails

| action | result |
|---|---|
| `attach` | succeeds, every device, every time |
| `tap` | succeeds (verified — taps landed on real UI targets) |
| `open_url` | succeeds (deep link opened the app) |
| `screenshot` | **crashes the service, every time** |
| `inspect` | returns "not available right now" |

Input injection is fine; only capture is broken.

## Variables ruled out

The crash reproduced identically across every variable that could be changed:

| variable | values tried | result |
|---|---|---|
| device | 3 distinct simulators | crash on all |
| iOS runtime | 26.5 and 27.0 | crash on both |
| screen size | iPhone 17 Pro (402x874 pt), iPhone 17 Pro Max (440x956 pt) | crash on both |
| `scale` parameter | omitted, 0.5, 0.4 | crash on all |
| Claude Code restart | full application restart | crash unchanged |
| device freshly booted | yes | crash unchanged |

The only constant is the host OS.

## Note on `simctl`

`xcrun simctl io screenshot ` works perfectly throughout, including
immediately after a failed Claude `screenshot` call. So the simulator itself,
CoreSimulator, and the display are all healthy — the failure is specific to the
integration's own capture path.

## Suspected cause

macOS 27.0 is pre-release, and this looks like a compatibility gap rather than a
configuration problem. A related-in-kind failure on the same machine: the
Command Line Tools ship `MacOSX27.0.sdk`, whose `libSystem.B.tbd` declares an
`arm64e.x1` architecture that Xcode 26.6's `tapi` rejects with
`ld: tapi error: malformed file ... unknown architecture`. Tooling built before
macOS 27 breaks on macOS 27 artifacts; the capture service may be hitting the
same class of issue (e.g. a ScreenCaptureKit or CoreSimulator API change).

## Impact

The integration is usable for automation (attach/tap/open_url) but not for its
primary stated purpose — letting the user watch the app and letting Claude
verify visually. Workaround is to drive the simulator through the Claude tool
and capture separately via `xcrun simctl io ... screenshot`, which is awkward
and leaves the panel blank for the user.

## Suggested improvements regardless of the root cause

1. `attach` reporting `Simulator panel opened for ...` is misleading when the
panel cannot render — it confirms the request, not the result. A failure or
warning here would surface the problem immediately instead of after the first
`screenshot`.
2. The crash message says "Try again in 1s" and "The simulator restarts itself",
which reads as transient. When the failure is persistent, repeated retries are
the wrong advice; a distinguishable persistent-failure error would help.

Start by reproducing the `screenshot` failure through the Claude Code iOS Simulator integration on macOS 27.0, then compare it with the working `xcrun simctl io screenshot ` command. Trace the capture path behind `screenshot`, `inspect`, and the live panel; done means screenshots and panel rendering work, or a persistent failure is surfaced with accurate guidance.

Written by the indexing model from the issue text.