[Sealdot]

Regenerating an iOS project while reusing Cargo's target cache can drop the custom URL schemes because the deep-link build script is still considered fresh.

Track the generated Info.plist and entitlements files, together with TAURI_IOS_PROJECT_PATH and TAURI_IOS_APP_NAME. Until a file exists, track its nearest existing parent so later generation is detected without making every unchanged build rerun. Existing plist update behavior and configuration mapping are preserved.

Fixes #3596.

Validation on macOS 27.0.1 arm64:

• The new pnpm test:deep-link-build regression runs the real plugin through Cargo with generated project fixtures. On both Rust/Cargo 1.97.1 and 1.90.0, the same 13 cases go from 3 passing / 10 failing on the base to 13 passing with this change. Cases cover regenerated and missing files, app/project changes, config changes, and a settled cache.
• Default/all-feature Clippy with -D warnings, 4 existing Rust unit tests, the Rust 1.90 check, Rust formatting, changeset/license checks, 28 plugin JS builds, workspace ESLint/Prettier, API E2E type checking, and the deep-link type check pass. The doc-test command succeeds with 0 tests.
• An additional tsc -p examples/api/tsconfig.json check reports seven identical pre-existing errors in utils.js on both base and candidate. The example has no ts:check script; its code is unchanged.

Native iOS acceptance on an arm64 iOS 27.0 Simulator (Xcode 27.0/27A266a, Rust/Cargo 1.97.1, Tauri core 2.12.0 and CLI 2.12.2):

• Run tauri ios init and tauri ios build --ci --debug --target aarch64-sim --no-sign, delete only gen/apple, then repeat init/build while retaining the Cargo target cache. The base's first app contains the configured scheme but its regenerated app loses it. Both candidate apps retain it; the candidate build-script output timestamp changes on regeneration while the base's does not.
• Install the actual candidate app from the warm-cache build and open its configured scheme with simctl openurl. After accepting the iOS system confirmation using XCTest, the exact URL is received by both the native on_open_url listener and the WebView deep-link://new-url listener. The base's regenerated app starts normally but rejects that scheme with LSApplicationWorkspaceErrorDomain 115.
• All four native builds use identical fixture code/config/lockfile; switching base to candidate changes only the plugin dependency path. Debug info is line-tables-only for the app and Tauri so the SDK Swift package remains in debug under Xcode 27 ([bug] [ios] Release build fails to link on Xcode 27: SwiftPM's default build system gives non-public @_cdecl functions local visibility tauri#16130). No SDK source patches, user development-team signing, or physical device were used.

Additional limitation: after terminating the app, a scheme URL relaunches it and the WebView becomes ready, but no startup URL payload reaches the fixture's native/JS listeners or get_current within 60 seconds. This occurs with both the base's valid first-build app and the candidate's warm-cache app; subsequent warm URL delivery works on both. That extra cold-start payload test is recorded as failing. Release builds and physical-device behavior have not been tested.

This PR stays draft pending author review and upstream CI. The five-file signed commit is unchanged.

AI assistance: OpenAI Codex.