Crypto diagnostic rejections can abort explicit bug reports

### Steps to reproduce

1. Configure Element Web with a bug-report endpoint and Sentry.
2. Make an optional crypto diagnostic reject. A deterministic example is
`getOwnDeviceKeys()` returning a rejected promise.
3. Open the bug-report dialog with an error or issue URL.
4. Submit the report.

This is a deterministic code-level reproduction. It does not establish how
frequently the rejection occurs in production.

### What did you expect?

The explicitly submitted report should continue. Diagnostic families
unrelated to the rejection should remain available.

### What happened instead?

- `collectBugReport()` rejects before returning its `FormData`.
- `sendSentryReport()` rejects before calling `captureException()` or
`captureMessage()`.
- A real Sentry Browser SDK using a network-free local transport serializes
zero envelopes.

One submission from the user can therefore lose both diagnostic channels.

This is distinct from #19391. That issue concerns global uncaught errors that
are absent from rageshakes. Here an explicit report starts, but a crypto
diagnostic rejection aborts it.

### Operating system

N/A — deterministic Jest/Vitest reproduction.

### Browser information

N/A — no browser-specific behavior is required.

### URL for webapp

N/A — local test environment.

### Application version

Element Web `develop` at
`7ffb0ffced8b93b7f4a697ff53b4344eb1c32fa6`.

### Homeserver

N/A — synthetic Matrix client.

### Will you send logs?

No. No production logs are required; the reproduction uses synthetic
identities, errors, device identifiers and DSN values.

### Proposed direction

- Treat thrown errors and rejected promises from diagnostic collectors as
best-effort failures.
- Preserve the primary report and unrelated diagnostic families.
- Keep rageshake fields already appended before a late rejection.
- Do not add payload fields or capture the auxiliary error.
- Emit only fixed failure-family warnings without messages, stacks or
identifiers. Existing breadcrumb/log pipelines may retain those warnings.
- Do not add an automatic reporting trigger or change the existing payload
schema.

I have a small local prototype with Jest regressions for both paths and a
real-SDK Sentry harness. I am happy to adjust the scope or split the work if
the maintainers prefer a different contribution shape.

Start by tracing collectBugReport() and sendSentryReport() and run the existing Jest/Vitest regressions described in the report, including the real-SDK Sentry harness. Verify behavior with getOwnDeviceKeys() returning a rejected promise. Done means the explicit report and unrelated diagnostic families still complete, prior rageshake fields remain, and only fixed failure-family warnings are emitted without changing the payload schema.

Written by the indexing model from the issue text.