includeWebFeedback: false leaves @sentry/browser's feedbackSync in bundles made on Windows, which then fail at launch #6913

Environment

• @sentry/react-native 8.29.0 (the same code is in 8.31.0)
• Expo SDK 57, React Native 0.86.3, Metro via getSentryExpoConfig
• Bundled on Windows 11 (eas update, which bundles locally)

Steps to reproduce

1. Use getSentryExpoConfig(__dirname, { includeWebFeedback: false }) in metro.config.js.
2. On Windows, run npx expo export --platform ios --source-maps (or eas update).
3. List the bundle's source map sources.

Expected result

As on macOS and Linux: @sentry/feedback is stubbed, and so are @sentry/browser's feedbackSync.js and feedbackAsync.js, as the comment above SENTRY_BROWSER_FEEDBACK_WRAPPER_RE describes.

Actual result

@sentry/feedback is stubbed, but @sentry/browser/build/npm/esm/prod/feedbackSync.js and feedbackAsync.js are bundled. feedbackSync.js calls buildFeedbackIntegration() from the empty module as it loads, so the bundle fails at launch. On an expo-updates update, the phone records a failed launch and falls back to its embedded bundle.

The cause is isFromSentryBrowser in dist/js/tools/metroconfig.js:

function isFromSentryBrowser(originModulePath) {
    return originModulePath.includes('@sentry/browser');
}

On Windows, Metro's context.originModulePath uses backslashes (...\node_modules\@sentry\browser\build\...), so this is never true. Matching either separator fixes it, for example /[\/]@sentry[\/]browser[\/]/.test(originModulePath).

Our workaround is to wrap config.resolver.resolveRequest after getSentryExpoConfig and return { type: 'empty' } for /\/feedback(Sync|Async)/ requested from a path matching that pattern.