fix(ios): answer scene configuration for the requested session role

[rubenmuehlhans]

What

On iOS, application:configurationForConnectingSceneSession:options: always answers with a
UIWindowSceneSessionRoleApplication configuration — the connecting_scene_session parameter is
unused, so the role the system is asking about is never read.

That method takes precedence over the app's UIApplicationSceneManifest. So when the system asks
about a non-window role, it gets a window configuration back and the scene never connects. The
app's manifest is correct, the delegate is registered, and nothing is logged — the scene simply
does not appear.

This affects any tao app that declares a second scene role. In our case that is CarPlay: the app
is entitled, the manifest declares a CPTemplateApplicationSceneSessionRoleApplication
configuration, and the app still does not show up on the CarPlay home screen. External displays
(UIWindowSceneSessionRoleExternalDisplayNonInteractive) are the same shape of problem.

How

Read the role from the connecting session and branch on it:

• window role (or nil) — unchanged: the TaoScene configuration with TaoSceneDelegate.
• any other role — build a configuration with nil as the name, which selects the first
  configuration the app's manifest declares for that role. tao therefore needs to know nothing
  about how the app named its scenes, and does not need a list of roles it supports.

The nil-name behaviour is documented under
UISceneConfiguration(name:sessionRole:).

No API change, no new dependency, no behaviour change for apps without a scene manifest.

Testing

• Verified in a shipping Tauri app (tao 0.35.3 with this change backported): CarPlay scene
  connects in the simulator and the app appears on the CarPlay home screen; the phone window is
  unaffected. Also verified on device (iPhone 15 Pro, iOS 26.6) that the normal window path still
  launches.
• cargo test passes; cargo check --target aarch64-apple-ios is clean on this branch.
• Not verified: external-display roles. The code path is the same, but I have not exercised it.

Note for the 0.35 line

While tracking this down we hit a second, separate bug that is already fixed on dev: 0.35.3
returns the configuration with Retained::as_ptr(&config), which releases the object before UIKit
retains it. It is harmless as long as no app declares a scene manifest, because iOS then never
calls this method at all — but with a manifest it is a hard EXC_BAD_ACCESS in
objc_retain from -[UIApplication _connectUISceneFromFBSScene:transitionContext:], on device,
about 70 ms into launch. dev already uses autorelease_ptr, so nothing to do here; mentioning it
only in case a 0.35 patch release is ever considered, since the two bugs meet in exactly the same
place.