feat(mobile): instrumentable iPad simulator for reproducing and profiling iPad-only defects #4

Problem

Most of my time in T3 Code is on the iPad app, and I cannot debug it from the Mac. When the iPad hangs (#3: a thread open freezes the whole UI until force-quit), the only evidence is a screenshot and my description. Server traces cannot show a blocked JS thread, and I cannot read the iPad's local cache or see what its JS thread is doing. #3 was investigated for an hour without finding the cause for that reason.

Goal

An iPad simulator setup that an agent or I can launch with one command and inspect, so a defect seen on the iPad can be reproduced and profiled on the Mac.

• Boots an iPad simulator with the dev client (see scripts/mobile-native-client.ts ensure and the test-t3-mobile workflow) paired to an isolated dev server.
• Seeds that server from a copy of my real data (VACUUM INTO, per AGENTS.md "Test data"), so large real threads like the one in bug(mobile): iPad thread open hangs on 'Syncing messages...' until force-quit #3 are available.
• Exposes instrumentation: JS thread stall detection (long-task or event-loop lag logging), the React Native JS profiler or a Hermes sampling profile, and a way to read the app's local SQLite cache for a given thread.
• Reproduces an open of a named thread, with a scripted tap, and reports whether the JS thread stayed responsive.
• Never touches ~/.t3/userdata read-write and never shares state with the live app.

First use

Reproduce #3 with the failing thread's data and find what blocks the JS thread. Fix or file the cause.

Priority

High. It unblocks every iPad-only defect, and iPad is my main surface. It also feeds the papercut capture work (docs/fork/papercuts.md): a stall detector built here is the same signal the automatic offer needs.

Related: #3, #2.