feat(faro-cli): support uploading a single source map to multiple applications in one invocation

### Summary

A customer wants to upload the same source map(s) to **multiple Faro applications in a single `@grafana/faro-cli` invocation**, without having to write their own wrapper scripts/loops around the CLI.

### Current behavior

The CLI (`@grafana/faro-cli`, `packages/faro-cli`) is strictly **one app per invocation**:

- `upload` (and `metro upload`) take a single `--app-id` / `-a`.
- The app ID is baked into the upload URL path: `${endpoint}/app/${appId}/sourcemaps/${bundleId}` (`packages/faro-cli/src/index.ts:190`, `packages/faro-cli/src/metro.ts:161`). It is not a payload field.
- `UploadOptions.appId` is a single string, not a list (`packages/faro-cli/src/cli.ts:11-28`).

To target N apps today, the customer must invoke the CLI N times:

```bash
npx faro-cli upload --app-id app1 --endpoint ... --stack-id ... --api-key ... --bundle-id ... --output-path ./dist
npx faro-cli upload --app-id app2 ...
npx faro-cli upload --app-id app3 ...
```

This forces customers to maintain their own shell loops/scripts — the exact friction this request is about.

### Desired behavior

A first-class way to fan one upload out to multiple application targets in a single command, so customers don't have to script it themselves. The CLI would iterate the targets, POSTing to each app's `…/app/{appId}/sourcemaps/{bundleId}` endpoint.

The exact UX is open for the team to design. Considerations worth weighing:

- **Per-app credentials/config.** Targets may differ in more than just `appId` — `stack-id`, `api-key`, and `endpoint` can vary per app. Any design should decide whether those are shared across targets or specified per target (e.g. a config-file approach scales better than repeated flags if creds differ; repeated/CSV `--app-id` is simplest when only the app ID changes).
- **Partial-failure semantics.** If 2 of 4 uploads succeed, what is the exit code and reporting? (Suggest: continue through all targets, summarize successes/failures, non-zero exit if any failed.)
- **`bundle-id` consistency** across targets.
- Applies to both the web `upload` path and the React Native `metro upload` path.

### Out of scope / notes

- The ingest API ties each upload to one app via the URL path, so this is a CLI-side fan-out, not an API change.
- Customer context: generic for now — internal customer request; account/Zendesk references to be added privately if needed.

Start in packages/faro-cli/src/cli.ts to understand UploadOptions, then trace the upload paths in packages/faro-cli/src/index.ts and packages/faro-cli/src/metro.ts. Define the multi-application configuration and partial-failure behavior before implementing it for both web upload and metro upload. Done means one invocation can target multiple applications and reports failures with an appropriate exit status.

Written by the indexing model from the issue text.