fix(apple): distinguish recoverable service-hub interruptions
Summary
A recoverable simulator service-hub interruption can log failed to bless service hub and then start XCTest about 2.935 seconds later. The current classifier aborts that launch as unsupported Xcode before the runner can answer.
Require the exact, delimited DTServiceHubClient Code=1 " / localDeviceConnectionWithError: signature from #3449 in the launch tail; its underlying error can follow the bless sentence on another line. Code=2/still-alive warnings and unproven bless failures retain ordinary behavior. This narrows the existing heuristic; it does not establish that every Code=1 error proves host incompatibility.
Three files changed: the classifier, captured excerpts, and transport regressions. No scope expansion, new retries, deadlines, or native changes. Fixes #3963.
Validation
- Head:
b683cb40afffb3608f6366cc8dc380f22231ea27; base:45125d717b207736dd47bc7969edbff7807a6e6d. - Original warning regressions fail on base; revised split-line and Code=10/100 checks fail four times against
b8358177d. All pass at head. - Focused suites: 76 tests pass. Independent review: no findings.
pnpm check:affected --run --head HEAD: passed,exactCommit: true. Format, lint, typecheck, layering, dead-code check, build, and 2,375 tests across 293 files passed.- Installed 0.21.29 with the initial two-term patch: an existing journey passed 5/5 checks headlessly on one simulator, zero retries, 153.466s including setup/cleanup; teardown completed with no retained leases. The warning did not recur, so this verifies neither live warning recovery nor this exact source commit. Deterministic regressions cover that recovery.
- Coverage, native Apple builds, and replay checks retain CI/manual obligations.