app:create document upload fails intermittently with masked 'Unexpected error.' (115); failure rate grows with batch size

### Summary

Since ~2026-08-31 07:20 UTC, `hive app:create` document uploads to Hive Cloud fail intermittently with the masked error:

```
› Error: Unexpected error. (Request ID: "03e80e83-a5d2-9038-b98c-e89dddbca3f4") [115]
```

The failure is **probabilistic per request and strongly correlated with batch size**, so the CLI's fixed 100-document upload chunks fail on effectively every run — our CI deploys were 100% blocked until we worked around it client-side.

### Environment

- Hive Cloud (staging target of our project — resolvable from the request IDs below)
- `@graphql-hive/cli` 0.61.5 (also verified nothing relevant changed up to 0.62.0)
- App deployment: our UI app, ~160 persisted documents (each 0.1–6 KB)
- Last fully successful identical upload: 2026-08-31 07:10 UTC

### Evidence it's server-side and probabilistic

- The same manifest that uploaded cleanly at 07:10 UTC fails from 07:34 UTC onward — no client-side change.
- Identical document subsets flip between pass and fail across consecutive runs (a 25-doc subset: fail, fail, pass; a different 25-doc subset: pass, fail, fail). Individual documents from failing subsets all upload fine alone.
- Failure rate grows with batch size: ~10 documents usually succeed, ~25 fail most of the time, 100 (the CLI default chunk) essentially always fails.
- Upload processing is also very slow right now: a single 152-character document took **7.3 s** server-side (`--debug`: `succeeded with status 200 (7s:329ms)`).
- "Unexpected error." + request ID looks like Yoga's masked unhandled-exception response, i.e. an exception inside `addDocumentsToAppDeployment` rather than a typed validation error (those come back with per-document details).

### Request IDs (all this incident, oldest first)

- `03e80e83-a5d2-9038-b98c-e89dddbca3f4` (2026-08-31 ~07:34 UTC, CI)
- `8165ad34-006c-9958-9ead-2e897788ebbb`
- `6dec8e2f-f64f-9a4a-b21b-f373bb61cd84`
- `2cc3d7c9-c3a9-954e-b901-ed018b5a62e1`
- `8e1d8998-417e-9cbc-af20-3885fb0ebd56`
- `3a31925f-83ec-94ad-9857-256e586c45e5`

### Workaround we shipped

Splitting the manifest into 10-document chunks and calling `app:create` repeatedly for the same name+version (documents accumulate on the pending deployment; re-adding an already-uploaded document is a no-op), with exponential-backoff retries per chunk, then `app:publish`. This works but is slow and shouldn't be necessary — related ask: #8410 (idempotent `app:create`/`app:publish`).

### Asks

1. Check the request IDs above for the underlying exception in `addDocumentsToAppDeployment`.
2. Consider surfacing the real error instead of the masked "Unexpected error." (same pain as #6478).
3. Consider retries and/or a configurable chunk size in the CLI, since one failed chunk currently aborts the whole upload.

Start by tracing the TypeScript CLI `app:create` upload path and the server-side `addDocumentsToAppDeployment` operation. Use the listed request IDs and the documented batch-size behavior to reproduce the failure and locate the underlying exception. Done means the agreed scope—server error visibility, upload resilience, or chunk-size handling—has a regression test and verified behavior.

Written by the indexing model from the issue text.