perf(ios): decide Simulator AX bridge viability with a bounded spike

[thymikee]

Parent: #2188

Blocked by: #2189, #2190

Outcome

Run a bounded, disposable iOS Simulator accessibility-acquisition spike and make an explicit GO or
NO-GO decision. The spike compares candidate mechanisms behind #2190's acquisition adapter and must
not alter production routing.

A fast result is insufficient: correctness, lifecycle, cancellation, and bounded-resource evidence
are mandatory. A NO-GO closes the bridge path cleanly while leaving the converged engine and provider
work useful.

Exact scope

• Compare viable host-side Simulator accessibility mechanisms through one batch acquisition adapter.
• Include a control using task-owned, pre-boot Simulator accessibility preferences such as
  AutomationEnabled and IgnoreAXServerEntitlements, plus related keys discovered during the
  spike.
• Apply preference experiments only to disposable task-owned Simulators before boot; record the
  exact plist diff and restore or delete the Simulator during cleanup.
• Use a framed request protocol with logs on stderr and one batch tree response; never per-node IPC.
• Report only acquired facts: raw nodes, viewport evidence, target generation, truncation, and typed
  residue. Do not implement visibility, hittability, scope, public depth, or semantic compaction in
  the reader.
• Bound request bytes, response bytes, node count, traversal depth, CPU work, memory, and duration.
• Model unsupported mechanism, malformed tree, stale target generation, timeout, cancellation,
  process crash, and transport failure as typed outcomes.
• Exercise quiet, list, nested-scroll, alert/system-surface, relaunch-during-capture, and XCTest-stress
  fixtures from test(ios): establish snapshot convergence baselines and permanent evidence #2189.

Measurement contract

Use #2189's harness and state definitions. Report raw samples for acquisition and prototype
daemon-side presentation separately, including CPU, memory, payload size, and crash recovery.

The route is viable only if evidence shows enough headroom for the program targets:

• cold-cold first look under 5 seconds after a clean install;
• cold prepared first look p95 under 1.5 seconds;
• warm daemon-resident snapshot p50 under 75 ms and p95 under 150 ms after integration;
• relaunch first look within 250 ms after app readiness;
• no increase in wrong-tree, stale-tree, or unreadable-tree publication.

These are go/no-go targets, not numbers to revise after observing the result. Classify #1571-style
app-mount unreadability separately from reader failure.

Decision output

Publish a checked-in spike report containing:

• candidate mechanisms and exact environment/toolchain;
• fidelity and limitation matrix;
• cold-cold, cold, warm, and relaunch raw results;
• lifecycle, crash, timeout, cancellation, and stale-generation results;
• private-interface and Simulator-preference compatibility risk;
• selected route and why, or a NO-GO with failed criteria;
• production interface changes, if any, needed by the next issue.

Non-goals

• No production backend selection, fallback, runner-demand, open/relaunch, or proxy change.
• Do not enable private Simulator preferences by default.
• No XCTest interaction change, physical-iPhone work, public CLI flag, or npm postinstall compiler.
• Do not keep a candidate merely because it is fast when fidelity or lifecycle gates fail.

Acceptance and evidence

• Every candidate runs through the same adapter contract and benchmark corpus.
• The selected candidate, if any, proves app and system-surface fidelity, target-generation handling,
  bounded resources, typed failures, cancellation, and recovery.
• Failure cases are reproducible and distinguish app readiness from acquisition failure.
• The report contains an explicit GO or NO-GO. The productionization issue must not start without GO.
• Focused harness/tool tests pass; live Simulator measurements and artifacts are attached.

Worker stop conditions

• Stop with NO-GO if no candidate satisfies correctness and lifecycle gates, even if latency is good.
• Stop if the experiment requires persistent host preference changes or affects non-task Simulators.
• Stop if the adapter must manufacture presentation semantics to make a candidate look complete.