perf(ios): match picker images from the page source, and make the masquerading avatar distinguishable

[mpretty-cyro]

Three related changes to how iOS picks an image out of the photo library. Stacked on #160 — both branches
touch DeviceWrapper.ts, in disjoint regions (dismissCTA there, matchAndTapImage here).

The masquerading avatar was indistinguishable from the file it masquerades as

animated_profile_picture_as_png.png was byte-identical to animated_profile_picture.gif, and both sit
in the simulator's photo library. iOS picks by matching pixels, so which of the two a run uploaded was
decided by tree order. Nothing in the accessibility tree separates them either: same name, and their
picker labels agree to the minute, both being stamped when simctl addmedia ran.

That matters for pro_animated_format_bypass, whose claim is that the client reads the bytes rather than
the extension. Handed the real .gif, the refusal it asserts is free — any client refuses that — so the
spec could pass while testing nothing.

It is now the colour inverse. Inversion is a per-pixel bijection, so the frames still differ exactly as
before and the file still animates; it scores -0.99999994 against the original under
TM_CCOEFF_NORMED, the matcher's default, against a 0.85 threshold.

Worth knowing for anyone checking this: ImageMagick's NCC metric calls the same pair a perfect 1.0.
That metric is not mean-subtracted, so it is invariant to inversion and cannot be used here.

Matching now costs two round-trips instead of N

matchAndTapImage asked XCUITest for the candidates, then screenshotted each one. Both are round-trips
WDA serialises, so cost scaled with the candidate count. Measured on the profile-picture picker:

findElements('xpath', '//XCUIElementTypeImage')	4969ms
one getElementScreenshot	586ms, ×23
getPageSource	1352ms

The tree already carries every rect, and reading all of it costs less than a third of the element query
alone. So candidates and geometry come from one page source, pixels from one screenshot, and cropping and
matching happen locally.

Only 10 of those 23 elements were photographs — the rest belong to the app behind the picker's sheet.
Every thumbnail carries PXGGridLayout-Info, so the profile-picture call site names it. Hence the
candidate argument is a type and an optional name rather than a locator: the set is resolved by parsing,
not by querying.

Two deliberate omissions. It does not consult visible — every element in that picker reports
visible="false", thumbnails included, so filtering on it would discard the targets. And it does not name
the candidates in the share-to-Session flow, which is the Photos app's own grid rather than the in-app
sheet and has not been measured.

pnpm create-simulators was broken

copy_file_to_simulator.ts had MEDIA_ROOT = run/test/media, a directory that no longer exists — fixtures
live in sample_files. The PDF preload threw, so the pool could not be rebuilt at all. create_ios_simulators
checks that PDF exists at its path before calling this, which resolved a different one, so the guard
passed and the copy failed.

Unrelated to the picker in subject, but a changed fixture cannot reach a simulator without it.

Verification

Every device class, both candidate paths:

	D=1	D=2	D=3
Image + PXGGridLayout-Info	✓	✓	—
Image unfiltered	—	✓	—
Cell	—	✓	✓

20 logged invocations across those runs, candidate counts perfectly stable (10 filtered, 11 cell) — so the
filter is not racing the grid load. Android Pass A green, 17/17, including both format-bypass specs, which
reach the inverted fixture by a different route (Android pushes the one file it needs and picks by name,
which is why it was never exposed to the twins).

Two specs each make exactly one uploadProfilePicture call and moved 58s → 41s and 45s → 32s.
Caveat: the simulator pool was recreated between those readings, so some of that could be a fresher pool.

Requires simulators to be recreated — the photo library is loaded once, at creation.