[bug] iOS (iOS 26.5): left part of the WebView is a touch dead zone in portrait (taps & swipes ignored), fine in landscape

### Describe the bug ## Environment - Platform: iOS only (Android & desktop fine) - Device: iPhone 15 - iOS version: 26.5 - Tauri: 2.11.5 - tauri-runtime-wry: 2.11.4 - wry: 0.55.1 - tao: 0.35.0 - App framework: Next.js (static export), App Router - Install: sideloaded signed IPA (not App Store) - Build: CI GitHub Actions, debug build ## Problem In portrait orientation, the left ~1/4 of the screen (starting from the physical left edge, full height, on every page) does not respond to taps or swipes . Tapping buttons, scrolling, and link-clicks in that region do nothing. The rest of the screen (right ~3/4) works normally, and there is no coordinate misalignment — content renders/positions correctly everywhere; only touches in that left strip are swallowed. In landscape orientation the problem disappears completely . ## Key diagnostic facts (already isolated) - Browser (mobile Safari on the same phone) works fine — the home screen and other apps also work fine on the left. So it is specific to this app's WKWebView, not the OS/hardware. - All pages are affected (including a near-empty diagnostic page with a full-screen touch grid that logs every touch/click coordinate). In portrait, the left quarter produces no touch/click JS events at all ; the right side logs coordinates correctly. - No CSS transform / translate3d is used on scroll containers; no full-screen transparent overlay exists. - set_size / set_position on the window is a no-op on iOS (tao Window::set_inner_size on iOS only logs a warning), so it is ruled out. - The WKWebView fills the parent view and auto-resizes ( ns_view.frame() + autoresizing mask), so the frame is correct. ## What we already tried (none fixed it) - Removed transform: translate3d(0,0,0) / will-change from scroll containers. - Registered tauri-plugin-ios-webview-insets to set WKWebView.scrollView.contentInsetAdjustmentBehavior = .never (verified the plugin's Swift code runs). Still broken in portrait. - Tested multiple builds; problem is persistent and portrait-only. ## Hypotheses / questions for maintainers 1. Is this a known iOS 26.x WebKit/WKWebView regression that manifests in portrait when the webview is full-bleed (edge-to-edge, viewport-fit=cover )? 2. Could it be related to how wry/tao creates the root UIViewController / adds the WKWebView on iOS (e.g., safe-area / scrollView content inset interacting with the full-screen layout)? 3. Is there a wry/tauri-side workaround to make the webview's touch hit-testing cover the full screen in portrait? Any pointers on what native property/configuration to adjust would be very helpful. Happy to provide more diagnostics or test a patch build. ### Reproduction _No response_ ### Expected behavior _No response_ ### Full `tauri info` output ```text [✔] Environment - OS: Mac OS 26.5.2 arm64 (GitHub Actions macOS runner) ✔ Xcode Command Line Tools: installed ✔ Xcode: 26.6 ✔ rustc: 1.97.1 (8bab26f4f 2026-07-14) ✔ cargo: 1.97.1 (c980f4866 2026-06-30) ✔ rustup: 1.29.0 (2026-03-05) ✔ Rust toolchain: stable-aarch64-apple-darwin - node: 22.23.1 - npm: 10.9.8 [-] Packages - tauri 🦀: 2.11.5 - tauri-build 🦀: 2.6.3 - wry 🦀: 0.55.1 - tao 🦀: 0.35.3 - tauri-cli 🦀: 2.11.4 - @tauri-apps/api ⱼₛ: 2.11.1 - @tauri-apps/cli ⱼₛ: 2.11.4 [-] Plugins - tauri-plugin-fs 🦀: 2.5.1 - tauri-plugin-http 🦀: 2.5.9 - tauri-plugin-opener 🦀: 2.5.4 - tauri-plugin-store 🦀: 2.4.4 [-] App - build-type: bundle - CSP: unset - frontendDist: ../out - devUrl: http://localhost:3000/ - framework: React (Next.js) - bundler: Webpack ``` ### Stack trace ```text ``` ### Additional context _No response_