Accept firebase-admin@^14.0.0 for firebase-frameworks peerDependencies

`firebase-admin` v14 was released and cannot be used with Firebase Hosting web frameworks, because `firebase-frameworks` still caps its `firebase-admin` peer range at `^13`.

Same shape as #361 (which widened the `firebase` range to `^12`), just for `firebase-admin`.

Current, on `main` in [`packages/firebase-frameworks/package.json`](https://github.com/firebase/apphosting-adapters/blob/main/packages/firebase-frameworks/package.json) (v0.11.9), and in published `0.11.8`:

```json
"firebase-admin": "^11.0.1 || ^12.0.0 || ^13.0.0"
```

### Impact

Any project on `firebase-admin@^14` fails `firebase deploy` / hosting channel deploys:

log output

```
npm error code ERESOLVE
npm error ERESOLVE could not resolve
npm error
npm error While resolving: firebase-frameworks@0.11.8
npm error Found: firebase-admin@14.2.0
npm error node_modules/firebase-admin
npm error firebase-admin@"^14.2.0" from the root project
npm error
npm error Could not resolve dependency:
npm error peer firebase-admin@"^11.0.1 || ^12.0.0 || ^13.0.0" from firebase-frameworks@0.11.8
npm error node_modules/firebase-frameworks
npm error firebase-frameworks@"^0.11.0" from the root project
npm error
npm error Conflicting peer dependency: firebase-admin@13.10.0
```

Worth noting this one is **not locally workaroundable**. The failing `npm i --omit dev` runs inside Cloud Build when packaging the SSR function, so setting `NPM_CONFIG_LEGACY_PEER_DEPS` in CI fixes only the CI runner's install and then fails identically on the builder. The only options today are pinning `firebase-admin` to v13 or dropping web frameworks.

### The range looks stale rather than load-bearing

`firebase-frameworks` touches a small, stable slice of the Admin SDK — [`packages/firebase-frameworks/src/firebase-aware.ts`](https://github.com/firebase/apphosting-adapters/blob/main/packages/firebase-frameworks/src/firebase-aware.ts):

```ts
import { initializeApp as initializeAdminApp, getApps } from "firebase-admin/app";
import { getAuth as getAdminAuth } from "firebase-admin/auth";
```

plus `verifyIdToken`, `createSessionCookie` and `verifySessionCookie` off `getAdminAuth()`.

All of those are unchanged in v14, including the `initializeApp(options?, appName?)` overload used by `initializeAdminApp(undefined, ADMIN_APP_NAME)`. v14's breaking changes were the removal of the **namespaced** API (`admin.firestore()`, `admin.apps`, `admin.credential.*`, `app.auth()`), the Instance ID service, legacy FCM types, and Node 18/20 support — none of which this file uses, since it is already fully modular.

So widening the range looks sufficient, with no code change:

```diff
- "firebase-admin": "^11.0.1 || ^12.0.0 || ^13.0.0"
+ "firebase-admin": "^11.0.1 || ^12.0.0 || ^13.0.0 || ^14.0.0"
```

One caveat worth flagging for whoever picks this up: v14 moved `@google-cloud/firestore` and `@google-cloud/storage` to `optionalDependencies` and requires Node >= 22, so if any release tooling installs with `--omit=optional` or targets an older Node, that's worth a look alongside the range bump.

Happy to open a PR if that's useful.