feat(ios): publish the keyboard band as a capture fact; guard prefers it over the tree heuristic #2660

Why

The keyboard band is measured twice, in two different ways, and only one of them is reliable.

• The runner already has the correct band. visibleKeyboardFrame(app:) in apple/runner/AgentDeviceRunner/AgentDeviceRunnerUITests/RunnerTests+Keyboard.swift (~line 136) reads app.keyboards.firstMatch.frame, which XCTest reports in the app's own orientation space. The scroll planner uses it for keyboardAvoided / keyboardMinY (RunnerScrollViewportPolicy.swift) and keyboard dismissal uses it too. PR fix(ios): publish captured keyboard geometry in the app's orientation space #2653 confirmed on device that this query answers the landscape band at y 198 where the tree reported a strip down the left edge.
• The daemon rebuilds the same band from tree nodes. packages/contracts/src/tap-keyboard-occlusion.ts (339 lines) finds anchor nodes, collects key rects, checks tiling and column runs, checks the docked bottom edge, and applies a width-versus-height guard to reject geometry that arrived unnormalized. src/commands/interaction/runtime/keyboard-occlusion.ts (107 lines) wraps it for every acting path. The golden table contracts/fixtures/tap-keyboard-occlusion-policy.json pins the heuristic.

The tree-derived rule exists because a capture carries no keyboard fact. Publishing one from the producer that can measure it collapses the iOS half of the heuristic to a point-in-rect check, removes the orientation dependence from the guard entirely (the guard would no longer care whether the tree was rotated), and lets the ADR 0004 paragraph "What stays unnormalized, and why the consumer rule stays" go.

Task

1. Carrier. Add an optional, producer-declared keyboard fact to the snapshot result. Suggested shape on the wire and in @agent-device/kernel/snapshot:

   keyboard?:
     | { kind: 'visible'; frame: Rect }        // app orientation space, same space as node rects
     | { kind: 'absent' }                        // producer looked and found none
     | { kind: 'unmeasurable'; reason: string }  // producer cannot measure on this path

   A producer that publishes nothing is unmeasurable by construction. Do not make it required on SnapshotResult: three client-side fallbacks rebuild results from a bare BackendSnapshotResult (see the refactor(ios): prune converged snapshot paths and close release gates #2199 prune notes in docs/adr/0004…, "Exactly-once made unrepresentable").
2. Runner. Read the band once per capture in snapshotFast / snapshotRaw (RunnerTests+Snapshot.swift) with the existing visibleKeyboardFrame(app:) and stamp it on DataPayload. It is one more XCUIElementQuery per capture; measure it (the scroll path already pays it per gesture) and report the number in the PR. Read it in the same main-thread hop as the viewport where possible so a rotation cannot land between the two reads. readAppleSnapshotResult in packages/platform-apple/src/runner/snapshot-presentation.ts carries it through.
3. Bridge. In portrait the keyboard window's subtree is already in the app's space, so the decoder in packages/platform-apple/src/snapshot-source/tree.ts can derive visible from the UIRemoteKeyboardWindow key plane exactly as tap-keyboard-occlusion.ts does today; after fix(ios): publish captured keyboard geometry in the app's orientation space #2653 a landscape capture with the keyboard up is refused by the bridge and served by the runner, so the bridge never has to answer that case. Publish unmeasurable when it cannot.
4. Guard. assertTapTargetClearOfVisibleKeyboard prefers the fact: visible → point-in-rect against frame; absent → no occlusion; unmeasurable or no fact → today's tree-derived rule, unchanged, which remains the path for Android (isAndroidInputMethodNode) and for appium-source / limrun-ios-tree. Keep resolveKeyboardTapOcclusion's public shape so the interaction-guarantee contract (packages/contracts/src/interaction-guarantees.ts, ADR 0011) does not change.
5. Docs. Update ADR 0004's "What stays unnormalized" paragraph and the tap-keyboard-occlusion.ts header comment to say the iOS runner path no longer reaches the width rule.

Acceptance criteria

• snapshot --json on the XCTest runner path carries keyboard: { kind: 'visible', frame } with the keyboard up and { kind: 'absent' } with it down, in portrait and in landscape, on iPhone 17 Pro (iOS 26.2 Simulator) and on one physical iPhone if available.
• The iOS reports the landscape iPhone keyboard's rects in the keyboard's own rotated space #2612 scenario (landscape, keyboard up, press @<ref behind keyboard>) is refused with tap_keyboard_occludes_target through the fact path (assert with a unit test that the tree-derived rule is not consulted when the fact is visible), and a target above the band still presses.
• Portrait behaviour is byte-identical on the runner path for snapshot -i --json apart from the new field (compare against main on the same screen).
• Android behaviour unchanged: packages/contracts/src/tap-keyboard-occlusion.test.ts and the Android integration lanes green with no fixture edits.
• Bridge path: portrait keyboard-up capture publishes visible with the same band the tree rule computed on main (assert equality in a unit test over a recorded bridge tree).
• Per-capture cost of the extra keyboard query on the runner path reported in the PR (p50 over 10 warm captures, keyboard up and down).
• pnpm check:affected --run green; Swift runner units green under AGENT_DEVICE_XCUITEST_INCLUDE_UNIT_TESTS=1 (see scripts/build-xcuitest-apple.sh); pnpm test:ios-snapshot-differential green.

Non-goals

Deleting the tree-derived rule. It stays for producers that publish no fact. Changing the keyboard-avoidance rule in the scroll planner (it already uses the live frame).

Related: #2612, #2653, #2589 (the guard), #2622 (find focus/type without the guard), ADR 0004, ADR 0011.