test(ios): reproduce #4394 keyboard opens on right-edge tap of non-cursor thought

[ethan-james]

cybersemics#4394

Summary

The iOS caret test 'Focus is prevented after clearing the cursor' was tapping the right edge with a synthetic point-tap. A zero-radius synthetic tap never triggers iOS Safari's touch-adjustment ("fuzzy tapping") retargeting, so the bug could never reproduce and the test always passed — it did not actually guard against cybersemics#4394.

This PR reworks the test to faithfully reproduce cybersemics#4394's exact steps on a non-cursor thought:

1. Create thought Hello
2. Dismiss the keyboard
3. Cursor Back (swipe right) to set the cursor to null — so Hello becomes a non-cursor thought (verified editing === null before the tap)
4. Tap ~4px past the right edge, vertically centered, using a finger-sized contact area (width/height/pressure)

Mechanism

The finger-sized contact area triggers iOS Safari's touch-adjustment heuristic:

touchstart (…) tgt=DIV#thought-annotation   ← touch lands on the annotation overlay
touchend   (…) tgt=DIV#thought-annotation   ← editable's onTouchEnd never fires → no preventDefault
mousedown  (…) tgt=DIV[EDITABLE]            ← Safari retargets the synthesized mouse events into the editable
focusin        tgt=DIV[EDITABLE]            ← focus proceeds
→ *** KEYBOARD OPEN ***

Because the touch events are dispatched on the annotation (not the editable), the editable's onTouchEnd never runs to preventDefault; Safari then redirects the mouse events into the editable and focus proceeds, so the virtual keyboard incorrectly opens.

Expected outcome

This test fails on this branch, demonstrating cybersemics#4394 (isKeyboardShown() returns true for a non-cursor thought). It will pass once focus is correctly prevented for non-cursor thoughts.

Notes

• A clickThought + scrollTo priming step is included: it is required for the synthetic touch to reliably win the timing race that a real finger triggers on its own. Locally reproduces the bug 3/3 with it, 0/3 without.
• getElementRectByScreen computes the status-bar offset per-device, so the tap coordinates should map correctly on BrowserStack hardware; the BrowserStack CI run is the definitive check that the bug reproduces there as it does on the local simulator.

[ethan-james]

Superseded by cybersemics#4534 (cross-repo PR against upstream).