iOS 27.1: back always refuses on the SwiftUI floating toolbar (top-band frame rule rejects the real control; leading fallback taps empty space) #3333

Purpose

back fails 100% of attempts on the iOS 27.1 Simulator when the app's navigation bar is the iOS 27 SwiftUI floating toolbar (observed on iPhone Duo, com.apple.Preferences General detail page). This makes the iOS Settings replay (test/integration/replays/ios/simulator/01-settings.ad) unable to pass its final step on the 27.1 runtime, and breaks back for any iOS 27 app using the floating bar.

Evidence (live, 2026-10-08, iPhone Duo 4F879835, iOS 27.1)

42/44 local replay attempts (12 cold+warm cycles with --retries 2, plus the first transient-daemon run) failed at step 7 back with in-app back control is not available while the screen provably sat on the General detail page (label=About visible, click General had truly navigated). Direct probe on that page: back failed 12/13 (one succeeded); click "role=button label=BackButton" failed 3/3 with selector_not_found (the control has no label, only identifier=BackButton); click @<ref> on that same button succeeded and navigated.

The page snapshot shows the back control:

{"role":"_UIFloatingBarContainerView","label":"Toolbar","identifier":"Toolbar","rect":{"x":0,"y":0,"width":466,"height":678}},
{"role":"_UIButtonBarButton","identifier":"BackButton","rect":{"x":399,"y":175,"width":38,"height":38},"hittable":true}

Runner log for one backInApp:

AGENT_DEVICE_RUNNER_SYNTHESIZED_DISPATCH kind=tap point=(37.3,105.1) reference=(0.0,0.0,466.0,678.0)
AGENT_DEVICE_RUNNER_IN_APP_BACK_VISUAL_VERIFICATION beforeBytes=290026 afterBytes=290026 changed=no
AGENT_DEVICE_RUNNER_COMMAND_COMPLETED command=backInApp ok=0

Mechanism, matching RunnerTests+Navigation.swift tier for tier:

1. app.navigationBars.buttons is empty — on iOS 27.1 the back control is a _UIButtonBarButton inside the _UIFloatingBarContainerView, not a child of the bar.
2. topNavigationBackElement finds the identifier match (BackButton hits the back keyword, isHittable=true), but isTopNavigationControlFrame rejects it: window height 678 gives maxY = min(max(678*0.22,96),180) = 149.2, while the control's midY = 194. The 27.1 floating bar sits lower than the classic navigation-bar band.
3. tapTopLeadingNavigationFallback synthesizes at (width*0.08, height*0.155) = (37.3, 105.1), which is empty window area on this surface — the bar is trailing, not leading.
4. Visual verification reads unchanged → .unavailable → in-app back control is not available.

CI cannot see this today because the iOS lane runs iPhone 17 Pro / iOS 26.x (isTopNavigationControlFrame passes there: 874-tall window gives maxY=180), and the 27.1 runtime ships only with the iPhone Duo device type, so this is a local-only lane condition (see docs/agents/device-verification.md).

Required behavior

• The runner must recognize the iOS 27 floating-bar back control (identifier/label keyword match outside navigationBars) without relying on the classic top-band height limit, or the fallback must aim at a point derived from the matched control rather than a fixed leading slot.
• Key the decision on the typed InAppBackOutcome, and keep the unknown-vs-unavailable split of fix(ios): use the resolved display for screenshots and visual verification #2728 intact.
• Do not regress the macOS/tvOS branches or the visual-verification refusal path.

Completion

• On iPhone Duo / iOS 27.1: back on the Settings General detail page navigates to root (is exists "label=About" false afterwards), and test/integration/replays/ios/simulator/01-settings.ad passes all 7 steps.
• A runner XCTest carries the band/fallback decision for the floating-bar frame shape.

Related: #2996 (closed; same container confused occlusion), #2948 (diagnostic run that found this), ADR 0025 (Duo coverage is local-only).