[BUG] Windows MSIX: Repair and Reset can never succeed — the installer registers the package from `%TEMP%\Claude-*.msix`, which is later deleted (0x80073CF0 / 0x80070002)

## Summary

Windows' built-in **Repair** and **Reset** for the Claude desktop app are permanently broken by a
packaging choice, not by a transient fault.

The installer registers the MSIX package from a temporary file in `%LOCALAPPDATA%\Temp\`. Windows
records that path as the package source. Both **Repair** and **Reset** re-run an `Add` deployment
against that recorded source path. Once `%TEMP%` is cleaned — which Windows does routinely — the
file is gone and both operations fail forever with:

```
AppX Deployment operation failed for package with error 0x80073CF0.
The specific error text for this failure is:
error 0x80070002: Opening the package from location Claude-3192053764.msix failed.
```

`0x80070002` = `ERROR_FILE_NOT_FOUND`.

The UI reports this as **"We couldn't repair this app. Try again in a bit."** That message is
misleading: the failure is deterministic and permanent. Waiting cannot help.

This matters because Windows itself directs users here. When the package needs remediation, Windows
displays:

> You'll need to go to advanced options for Claude and select Repair. If you're still having issues
> with it, reinstall this app or contact your administrator.

Following that instruction leads to two guaranteed failures, after which the only remaining option
is uninstall + reinstall — which has its own destructive consequence (see the linked issue below).

## Environment

| Item | Value |
|---|---|
| App version | 1.34493.1.0 |
| Package full name | `Claude_1.34493.1.0_x64__pzs8sxrjxfjjc` |
| Install type | MSIX, `SignatureKind: Developer` |
| Install source | https://claude.ai/download |
| OS | Windows 11 Pro 10.0.26200, x64 |

## Steps to reproduce

1. Install Claude Desktop from https://claude.ai/download.
2. Wait for `%TEMP%` to be cleaned (Storage Sense, Disk Cleanup, a reboot cycle, or manual
deletion). Confirm no `Claude*.msix` remains in `%LOCALAPPDATA%\Temp`.
3. Go to **Settings → Apps → Claude → Advanced options**.
4. Click **Repair** → fails.
5. Click **Reset** → fails.

Both fail regardless of the app's actual state.

## Evidence

From `Microsoft-Windows-AppXDeploymentServer/Operational`:

**Original install** — note the source path:

```
02:04:12 603 Started deployment Add operation on a package with main parameter
Claude-3192053764.msix
02:04:12 854 Successfully added the following uri(s) to be processed:
file:///C:/Users//AppData/Local/Temp/Claude-3192053764.msix
02:04:17 400 Deployment Add operation ... finished successfully.
```

**Repair attempts, ~15 hours later:**

```
16:52:40 603 Started deployment RepairPackageOperation
16:52:40 603 Started deployment Add operation
16:52:41 404 ERROR AppX Deployment operation failed with error 0x80073CF0.
error 0x80070002: Opening the package from location
Claude-3192053764.msix failed.
16:52:44 603 Started deployment RepairPackageOperation (retry)
16:52:44 404 ERROR ... same 0x80073CF0
```

**Reset attempt:**

```
16:53:01 603 Started deployment ResetPackageOperation
16:53:01 603 Started deployment Add operation
16:53:01 404 ERROR ... same 0x80073CF0
16:53:02 400 OK: Remove <-- destructive sub-operation succeeded
16:53:02 400 OK: StageUserData
16:53:03 400 OK: Register
```

Confirmed on disk: `%LOCALAPPDATA%\Temp\Claude-3192053764.msix` does not exist, and no `Claude*.msix`
remains anywhere in `%TEMP%`.

## Secondary defect: Reset reports failure after already destroying data

As the trace above shows, `ResetPackageOperation` reported failure to the user, but its `Remove`
sub-operation had **already succeeded**. The user sees "We couldn't reset this app" while the app
data has in fact been wiped. This is the worst possible combination: an error message that implies
nothing happened, after something irreversible happened.

## Context: the underlying problem had already fixed itself

In my case the package's ACLs were damaged across a sleep/wake cycle. Windows detected this and
showed the "select Repair" prompt. But 18 seconds after wake, an automatic
`RegisterByPackageFullName` had already resolved it:

```
16:50:28 649 Deployment Register operation ... Trying to repair ACLs for
\\?\C:\Program Files\WindowsApps\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc
16:50:28 649 Deployment Register operation ... ACLs repaired successfully
16:51:02 400 OK: Register
```

The package was already healthy. Following Windows' on-screen instruction to run Repair — and then
Reset, and then reinstall — is what caused the actual damage.

## Expected behaviour

1. Retain a durable copy of the `.msix`, or register the package from a stable location outside
`%TEMP%`, so Repair and Reset keep working for the life of the installation.
2. Do not report "Try again in a bit" for a deterministic, permanent failure.
3. Reset must not perform its destructive `Remove` before it has confirmed it can complete.

## Related

- #88692 — the destructive consequence of having no working Repair/Reset: the forced reinstall regenerates the device identity and permanently orphans existing Claude Code sessions
- #88068 — reports Repair/Reset failing on Windows, but with different error codes
(`0x80073CF6` / `0x80073CFA`) and no root cause identified
- #88138 — package transitioning to `Modified, NeedsRemediation`
- #87314 — ACL corruption in the package directory

I believe the `%TEMP%` source-path root cause above has not been reported before, and it is a
straightforward fix.

The payload names no repository files or tests. Start by locating the Windows/MSIX installer packaging and the code that registers the package from `%TEMP%`; reproduce the missing-source Repair/Reset failure, then verify installations retain a durable source and Reset does not remove data before completion.

Rédigé par le modèle d'indexation à partir du texte de l'issue.