winget/MSI upgrade 4.12.1 -> 4.14.0 deletes Azure.Security.KeyVault.Secrets.dll, breaking only `func start`

## Problem

Upgrading the Windows x64 MSI in place from **4.12.1 to 4.14.0** (via `winget upgrade`) **deletes `Azure.Security.KeyVault.Secrets.dll`** from the install directory. The file is present in a clean 4.12.1 install and in a clean 4.14.0 install, but absent after the upgrade.

Only the `start` action needs that assembly, so the result is that `func start` — and nothing else — dies with a bare `TargetInvocationException` and exit code 1:

```
Exception has been thrown by the target of an invocation.
```

`func --version`, `func --help`, `func new --help`, `func azure --help` all keep working, which makes it look like a project problem rather than a broken install.

## Minimal repro

No function app required — `--help` on the action is enough, because the failure is in the action's construction:

```
winget install --id Microsoft.Azure.FunctionsCoreTools --exact --version 4.12.1
func start --help # exit 0, prints help

winget upgrade --id Microsoft.Azure.FunctionsCoreTools --exact
func start --help # exit 1, "Exception has been thrown by the target of an invocation."

func new --help # exit 0 — still fine
```

A clean install of 4.14.0 (`winget uninstall` first, then `winget install --version 4.14.0`) works correctly.

With a real app, `func start --verbose` prints nothing after:

```
'local.settings.json' found in root directory (...)
Resolving worker runtime to 'dotnet-isolated'.
```

then exits 1 with the same message on stderr. Nothing is written to the Windows Event Log.

## Evidence

Full recursive file inventory of the install directory, clean 4.14.0 vs upgraded-to-4.14.0:

| install | files |
| --- | --- |
| clean 4.14.0 | 9068 |
| 4.12.1 upgraded in place to 4.14.0 | 9067 |

The diff is exactly one file, and nothing is left over from 4.12.1:

```
present in clean 4.14.0 but MISSING after upgrade:
\Azure.Security.KeyVault.Secrets.dll
```

`func.deps.json` declares `Azure.Security.KeyVault.Secrets/4.6.0`.

Copying **only** that one DLL (v4.6.0) back into the install directory makes `func start` work again on the upgraded install, with no other change. That confirms the missing file is the whole cause.

## Likely cause

Looks like MSI major-upgrade sequencing — `RemoveExistingProducts` scheduled such that uninstalling the old product removes a file the new package already installed (or a component/file-versioning rule that lets the older package win for this one file). The DLL is not in a versioned-file-wins position: it is the only file affected out of 9068.

## Workaround

Uninstall before installing, rather than upgrading in place:

```
winget uninstall --id Microsoft.Azure.FunctionsCoreTools --exact
winget install --id Microsoft.Azure.FunctionsCoreTools --exact
```

## Environment

- Windows 11 Home 26200, x64
- Core Tools 4.12.1 → 4.14.0, MSI from winget (`func-cli-4.14.0-x64.msi`)
- Host runtime after clean 4.14.0: 4.1052.200
- App: .NET 10 isolated (`dotnet-isolated`), though the repro does not need an app at all

## Note

This is easy to misdiagnose. On a .NET 10 isolated app, 4.12.1 fails separately with `Could not load file or assembly 'Microsoft.Extensions.Options, Version=10.0.0.0'` (4.13.0+ is self-contained on .NET 10 and supplies it), so "upgrade Core Tools" is the natural fix — and the upgrade then produces this unrelated, much more opaque failure. Possibly related family: #5579.

Reproduce the in-place 4.12.1 to 4.14.0 upgrade with winget and compare the clean and upgraded func-cli-4.14.0-x64.msi installations. Start by examining RemoveExistingProducts sequencing and component/file-versioning behavior; done means Azure.Security.KeyVault.Secrets.dll remains after upgrade and func start --help exits successfully.

Written by the indexing model from the issue text.