Evaluate the iOS crash-reporting backend

## Description

React Native iOS currently uses PLCrashReporter to capture crashes and recover pending reports. Before adding more iOS crash work, compare whether we should keep it or move to KSCrash or MetricKit.

This is separate from the session-correlation behavior tracked in [app-o11y-kwl#3762](https://github.com/grafana/app-o11y-kwl/issues/3762) and does not block [#143](https://github.com/grafana/faro-react-native-sdk/pull/143).

## What to compare

- project maintenance and supported iOS versions
- crash-time metadata and session correlation
- pending-report recovery and acknowledgement
- stack traces and symbolication support
- migration effort and compatibility with the shared JavaScript replay flow
- whether MetricKit is a replacement or a useful additional signal

## Acceptance criteria

- [ ] The three options and their trade-offs are documented.
- [ ] The preferred backend is agreed with the team.
- [ ] Any migration or follow-up implementation work is split into focused issues.

Start by reviewing the current React Native iOS integration with PLCrashReporter, then compare PLCrashReporter, KSCrash, and MetricKit against the listed maintenance, metadata, recovery, symbolication, migration, and replay-flow criteria. Document the trade-offs, record the team's preferred backend, and split any migration or implementation work into focused follow-up issues.

Written by the indexing model from the issue text.