aspire init should augment existing package.json for brownfield TypeScript apphosts

## Summary

`aspire init` for TypeScript/polyglot AppHosts is destructive in brownfield repositories that already have a root `package.json` and `tsconfig.json`.

A common repro is a frontend app created with `npm create vite`, where the repo root already contains the app's package metadata and TypeScript configuration. Running `aspire init` in that directory currently replaces the existing `package.json`, writes a new root `tsconfig.json`, and drops generic script names like `start`, `build`, and `dev` that are likely to collide with the app's own scripts.

## Repro

1. Create a Vite app at the repo root:
```bash
npm create vite@latest . -- --template vanilla-ts --no-interactive
npm install
```
2. Run:
```bash
aspire init
```
3. Select `TypeScript (Node.js)`.

## Current behavior

- The existing root `package.json` is overwritten.
- The existing root `tsconfig.json` is overwritten.
- The scaffolded scripts use generic names (`start`, `build`, `dev`) that are likely to conflict with existing frontend tooling conventions.

## Expected behavior

- If a root `package.json` already exists, `aspire init` should augment it instead of replacing it.
- Aspire-owned scripts should use Aspire-prefixed names based on the current scaffolded names:
- `aspire:start`
- `aspire:build`
- `aspire:dev`
- Existing root TypeScript configuration should be preserved; Aspire should use an apphost-specific config file if it needs its own TS config.
- The generated TypeScript AppHost should still run successfully after init.

## Scope for the spike

- Focus first on npm/Vite-style brownfield repos on the `release/13.2` line.
- Preserve existing dependency versions when a required package already exists unless testing proves Aspire must override them.
- Add CLI E2E coverage for the brownfield init scenario.

## Acceptance criteria

- `aspire init` no longer overwrites an existing brownfield `package.json` in a TypeScript repo.
- `aspire init` no longer overwrites an existing root `tsconfig.json` in this scenario.
- Aspire-specific scripts are added with Aspire-prefixed names.
- Targeted tests and a CLI E2E test cover the scenario.