fix(sentry): repair Android source-map upload (debug IDs + release/dist match)

Releases 0.4.3-0.4.7 uploaded zero source-map files to Sentry, leaving every
JS frame unsymbolicated (app:///index.android.bundle:1). Root-caused two
independent bugs:

1. No metro.config.js existed, so Metro never ran Sentry's debug-ID
   injection. Without an embedded debug ID, sentry.gradle's upload task
   falls back to matching source maps to events by release/dist string
   alone (see has-sourcemap-debugid.js check in sentry.gradle) - and that
   fallback was broken (see #2). Added metro.config.js wrapping Expo's
   default config with getSentryExpoConfig from @sentry/react-native/metro,
   the officially documented path for Expo + debug-ID symbolication.

   The installed @sentry/react-native@6.14.0 could not actually bundle with
   this enabled: its metro integration does a hard `require("metro/src/lib/
   countLines")`, a deep path metro 0.83.x (bundled by Expo SDK 54) no
   longer exposes via its package.json `exports` map, crashing every build.
   Bumped to ~6.22.0 (package.json:18), which vendors countLines and adds
   metro/private/* fallbacks for other deep metro imports. Verified via a
   real `npx expo export:embed` run: bundle and source map now share a
   matching `debugId`.

2. sentry.gradle's default release/dist for the upload is
   `${applicationId}@${versionName}+${versionCode}` (computed from
   android/app/build.gradle), which never matched what Sentry.init() reports
   at runtime (`opencode-mobile@${app.json version}`, src/lib/sentry.ts:33-34).
   Every source map was therefore filed under a release Sentry never
   queries. Added a "Set Sentry release identifiers" step to build.yml,
   publish-play-store.yml, and publish-fdroid.yml that exports
   SENTRY_RELEASE/SENTRY_DIST from app.json's version before the Gradle
   build step, forcing an exact match.

Also filled in organization/project on the `@sentry/react-native/expo`
plugin in app.json (previously a bare string, which only warned "Missing
config for organization, project" and relied on env-var fallback) so
android/sentry.properties is generated deterministically instead of by
accident/history.

Verified locally (no push - GitHub is down, consolidating to local main):
- npx expo export:embed (real Metro bundle) succeeds and embeds a matching
  debugId in both index.android.bundle and its .map
- npm run typecheck: clean
- npm test: 81/81 passing
- Full ./gradlew Android build not verified: this machine has no
  ANDROID_HOME/SDK and a JDK/Gradle-wrapper version mismatch unrelated to
  this change; CI's Java 17 + Android SDK toolchain is unaffected.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NJKAQ6HAikWGQK7PGZ5Y4E

metro.config.js

@@ -0,0 +1,22 @@
+// Metro bundler config.
+//
+// Wraps Expo's default Metro config with Sentry's config so the JS bundle
+// gets a Debug ID embedded at build time (see
+// https://docs.sentry.io/platforms/react-native/manual-setup/metro/).
+//
+// Why this matters: without this, Metro/Hermes produce bundles + source maps
+// with NO debug ID. `android/sentry.gradle` (applied from
+// android/app/build.gradle) then falls back to associating the uploaded
+// source map with Sentry purely by `--release`/`--dist` string matching
+// (see its `has-sourcemap-debugid.js` check). That legacy path is fragile —
+// it silently breaks if the release/dist Gradle computes for the upload
+// ever drifts from the release/dist the app reports at runtime via
+// `Sentry.init()` (src/lib/sentry.ts). Debug ID matching sidesteps that
+// entire class of bug: the bundle and its source map are linked by an
+// embedded ID, independent of any release/dist string.
+const { getSentryExpoConfig } = require("@sentry/react-native/metro")
+
+/** @type {import('expo/metro-config').MetroConfig} */
+const config = getSentryExpoConfig(__dirname)
+
+module.exports = config