fix(ios): distinct lineage for in-place system-surface captures (verify/settle)

[thymikee]

Follow-up to #2438 / #2448.

Purpose. A capture served from a system surface (SafariViewService sheet) must not be comparable to an app-baseline capture, or --verify/--settle could diff a sheet against the app and misreport.

Required behavior. Carry the runner's systemSurface provenance into the iOS snapshot comparisonIdentity/lineage so a system-surface capture and an app capture are never treated as the same presentation. Post-tap corroboration (hasMatchingPresentation) and --settle diffs must refuse to compare across the app↔sheet boundary.

Observable completion. A --settle/--verify around an interaction that crosses into or out of the sheet does not produce a spurious diff; a unit test pins the identity mismatch.

Dependencies. #2448 already threads systemSurface through readAppleSnapshotResult; this wires it into lineage. See Fable rule 5 in the #2448 ADR amendment.

[thymikee]

Folded into #2448 following review there, rather than shipping separately: the maintainer's read was that comparison across this boundary must not be left open while the in-place serve lands.

The surface identity now reaches SnapshotState as iosSystemSurfaceBundleId, and hasMatchingPresentation refuses outright when a baseline and a post-action capture disagree about it — so an app capture and a sheet capture can no longer meet in legacy same-presentation matching, including recorded-tap failure corroboration. Covered by a regression test in interaction-ios-tap-outcome.test.ts.

Closing once #2448 merges.