Make localhive installs self-contained like PR dogfood installs

## Problem

Validated locally against `origin/main` at `85c5178aa19fcb367d9b2213807db7f12615683e`.

Today the PR dogfood installer has an isolated install layout for archive installs:

- `eng/scripts/get-aspire-cli-pr.sh` installs PR CLI binaries under `/dogfood/pr-/bin`.
- `eng/scripts/get-aspire-cli-pr.ps1` uses the same PR-scoped layout.
- PR packages go into `/hives/pr-/packages`.

That keeps a dogfooded PR CLI separate from the regular Aspire install under `/bin`.

The `localhive` scripts do not have an equivalent isolated default layout today:

- `localhive.sh` defaults `ASPIRE_ROOT` to `$HOME/.aspire`, installs the CLI to `$HOME/.aspire/bin`, creates hives under `$HOME/.aspire/hives//packages`, and sets the global channel to `` when `--output` is not used.
- `localhive.ps1` mirrors that behavior with `$HOME/.aspire/bin` and `$HOME/.aspire/hives//packages`.
- Both scripts have an explicit `--output` / `-Output` portable-layout option, but the default local developer flow still writes into the shared Aspire prefix and can overwrite/disturb the real global install/config.

## Expected behavior

Local developer installs from `localhive.sh` / `localhive.ps1` should be self-contained by default, similar to PR dogfood installs. For example, install the locally-built CLI under a scoped directory such as `/local//bin` (or another agreed local-scoped layout) instead of the shared `/bin`.

The local package hive should remain discoverable by the CLI, but running `localhive` should not overwrite the regular global Aspire CLI install or mutate global config unless the user explicitly opts into that behavior.

## Why this matters

A local source build should be easy to try without disturbing the user's actual global Aspire install. PR dogfood installs already model this with a scoped directory; local hive installs should provide the same safety.