test: real CLI install scenarios — cross-route mixing, side-by-side, self-update

## Summary

We don't have real end-to-end CLI install tests that exercise multiple
acquisition routes mixing, side-by-side, or going through a full
install → self-update → uninstall lifecycle against a real installed
binary.

Each install route (winget, homebrew, script, dotnet-tool) has unit
tests and we run a per-route smoke install in CI workflows, but the
combinations are uncovered. This is the test layer that catches bugs
in the route-detection / first-run probe / extract-dir / sidecar chain
when exercised against a real installed CLI.

## Scenarios worth covering

A non-exhaustive starting set:

- Install via winget → `aspire update` → winget uninstall.
- Install via script → `aspire update` → script uninstall.
- Install via dotnet-tool → `aspire update` → tool uninstall.
- Install via route A, then install via route B — what wins on PATH?
what does `aspire doctor` report?
- Side-by-side coexistence: winget user install + script install in
`~/.aspire`; dotnet-tool install alongside winget.
- Self-update from a managed route (winget/homebrew/dotnet-tool) where
in-place update should be blocked or delegated.

These tests are heavy (mutate user state, real installers, real
uninstalls). Harness shape and project layout to be decided on
implementation.

Start by deciding the end-to-end test harness shape and project layout for real installed binaries, real installers, and real uninstalls. Cover the listed winget, script, dotnet-tool, route-mixing, side-by-side, and self-update scenarios; done means the combinations exercise route detection, first-run probing, extract directories, sidecars, PATH precedence, and doctor reporting.

Written by the indexing model from the issue text.