Define a consistent install-route layout under `~/.aspire/`

**Summary**

`~/.aspire/` is accumulating ad-hoc per-install-route subdirectories without a shared convention. Each new install route picks its own subdir shape, and there's no documented contract for where a route is allowed to plant state. We should define the layout and reconcile the existing routes before shipping more.

**Current state**

| Route | Path under `~/.aspire/` |
|---|---|
| Script (release installer) | `bin/aspire` |
| localhive | `bin/aspire` (same as Script) |
| PR / dogfood (`get-aspire-cli-pr`) | `dogfood/pr-/bin/aspire` |
| npm (#17297) | `npm///bin/aspire` |
| Bundles (extracted by any route) | mixed locations at the `~/.aspire/` root and per-route hive subdirs |

Observations:

- Script and localhive share `bin/`, which is fine, but a Script install followed by a localhive install (or vice versa) clobbers the previous one with no warning.
- PR installer uses a route-prefix (`dogfood/`) plus a discriminator (`pr-`) — a different shape from anything else.
- npm uses a route-prefix (`npm/`) plus version plus RID — yet a third shape (and the `` segment is being questioned separately in https://github.com/microsoft/aspire/pull/17297#discussion_r3330884648).
- WinGet/Brew/DotnetTool install outside `~/.aspire/` entirely (managed by their respective tools), so the routes that DO live under `~/.aspire/` are an inconsistent subset.

**What "cleanup" should produce**

- A documented convention for where each install route's binaries and per-route state live under `~/.aspire/` (e.g. `~/.aspire/routes///bin/aspire` as one option among others).
- A migration story for installs that already exist in the old shape.
- A single place that defines the layout (alongside `docs/specs/install-routes.md`).
- Bundle extraction continues to live at `~/.aspire/` and is shared across routes (current behavior; just make it explicit in the spec).

**Background**

David Negstad has work in flight that touches this area; coordinating with that work is the natural place to land the cleanup. The npm route added in #17297 is consistent with the rest of the (currently inconsistent) status quo and isn't a blocker — it just adds to the inconsistency rather than reducing it.

**Target milestone**

13.5.