[Windows] Crash (E_BOUNDS / invalid vector subscript) when selecting a Tab with nested ShellContent from the TabBar overflow menu

### Description

On Windows the app terminates with an unhandled `E_BOUNDS` raised inside `Microsoft.UI.Xaml.dll` when a Shell `Tab` that has **more than one** `ShellContent` child is selected from the TabBar overflow ("More", `...`) menu.

The crash requires **both** conditions at the same time:

1. the `Tab` has more than one nested `ShellContent` (i.e. it renders secondary tabs), **and**
2. that `Tab` is currently in the overflow menu instead of being directly visible in the TabBar.

Either condition on its own is fine. Counter-checks, all three verified in the linked repro:

| Action | Result |
|---|---|
| Select the tab with nested `ShellContent` from the overflow menu | **crash** |
| Select any single-`ShellContent` tab from the same overflow menu | works |
| Widen the window so the same tab sits directly in the TabBar, then click it | works |

So the overflow menu alone is not the problem, and nested `ShellContent` alone is not the problem — only the combination fails.

One further observation from the production app where this was originally found (not re-tested in the minimal repro): activating the very same tab programmatically via `GoToAsync("//main/")` while it is still in the overflow menu also works. Only going through the overflow menu UI crashes.

Native exception sequence from the Visual Studio output window:

```
Exception thrown at 0x00007FFC222F187A in App.exe: Microsoft C++ exception: std::out_of_range
Exception thrown at 0x00007FFC222F187A in App.exe: Microsoft C++ exception: [rethrow]
Exception thrown at 0x00007FFC222F187A (KernelBase.dll) in App.exe: WinRT originate error - 0x8000000B : 'invalid vector subscript'.
Exception thrown at 0x00007FFC222F187A in App.exe: Microsoft C++ exception: winrt::hresult_out_of_bounds
Microsoft.UI.Xaml.dll!00007FFA867E8DB3: 8000000B - E_BOUNDS
```

Continuing in the debugger then terminates the process with `0xC000027B: An application-internal exception`.

This was originally found in a production app with 12 tabs, exactly one of which had nested `ShellContent` — that was the only tab that ever crashed. It reproduces 100% of the time there and in the minimal repro below.

### Steps to Reproduce

1. Clone the reproduction project (an unmodified `dotnet new maui` project; **only `AppShell.xaml` was changed**).
2. Build and run on Windows:
`dotnet build -f net10.0-windows10.0.19041.0 -c Debug`, then start the produced `MauiShellOverflowRepro.exe` (the project is unpackaged, `WindowsPackageType=None`).
3. Resize the window narrow enough that the last tab, **"Nested"**, moves into the `...` overflow menu.
4. Open the overflow menu and click **"Nested"**.

**Expected:** the tab is activated and its secondary tabs ("Sub A" / "Sub B") are shown.

**Actual:** `E_BOUNDS` is thrown inside `Microsoft.UI.Xaml.dll` and the app terminates.

The relevant part of `AppShell.xaml` — the seven single-`ShellContent` tabs exist only to push "Nested" into the overflow menu on a normally sized window:

```xml

```

### Link to public reproduction project repository

https://github.com/Onkel2006/maui-shell-overflow-nested-shellcontent-repro

### Version with bug

.NET 10, `Microsoft.Maui.Controls` 10.0.80
Workload version 10.0.101.1, `maui-windows` 10.0.1/10.0.100

### Is this a regression from previous behavior?

No or unknown. We only noticed it recently because our window is normally wide enough that the affected tab never lands in the overflow menu. It reproduces in our shipping build too, so it is not something we introduced — but we cannot say whether an earlier .NET/MAUI version behaved differently, because nobody had narrowed the window before.

### Last version that worked well

Unknown/Other

### Affected platforms

Windows

Not verified on Android/iOS/macOS — those platforms render the overflow differently (BottomSheet / MoreNavigationController), so the same code path may not exist there.

### Affected platform versions

Windows 11 Pro 10.0.26200, target `net10.0-windows10.0.19041.0`, min `10.0.17763.0`

### Did you find any workaround?

Yes. Give the affected `Tab` a single `ShellContent` and reach the former sub-pages through regular registered routes (`Routing.RegisterRoute`) plus an in-page navigation bar.

Reordering tabs so the affected one stays out of the overflow is **not** a reliable workaround: on a sufficiently narrow window any tab ends up in the overflow again.

Clone the linked reproduction and run the Windows build command, then inspect the changed AppShell.xaml and reproduce the crash with the Nested tab in the overflow menu. Trace the Windows MAUI Shell TabBar overflow-selection path and compare it with direct or programmatic activation; done means the Nested tab activates without E_BOUNDS and shows Sub A and Sub B.

Written by the indexing model from the issue text.