Remove R8 proguard-rules sync tooling once jnigen auto-generates keep rules

[lucas-zimerman]

Description

packages/flutter currently regenerates and syncs its io.sentry.* R8/ProGuard keep rules by hand from ffi-jni.yaml, because jnigen doesn't yet produce keep rules itself:

• packages/flutter/scripts/generate-sentry-java-proguard.sh regenerates the AUTO-GENERATED-START/END block in android/proguard-rules.pro from the classes: entries in ffi-jni.yaml
• A CI step in .github/workflows/flutter.yml runs that script and fails the build if proguard-rules.pro drifts out of sync

This is a workaround for dart-lang/native#681. Once that lands and our jnigen dev-dependency is upgraded to a version that generates R8 keep rules itself, the sync script and its CI step become redundant and should be removed:

• packages/flutter/scripts/generate-sentry-java-proguard.sh
• the "Regenerate proguard rules from ffi-jni.yaml" / "Fail if proguard rules are out of sync" CI step
• the hand-maintained AUTO-GENERATED-START/END block and its header comment in android/proguard-rules.pro (replaced by whatever jnigen produces)

This is dev/CI-only tooling — jnigen is a dev_dependency, and the generated file is committed and shipped as-is to consumers — so removal isn't gated on a minimum Dart/Flutter SDK bump, only on bumping the local jnigen version once the upstream feature ships.

Keep packages/flutter/scripts/verify-proguard-mapping.sh and its CI job: it builds the example app in release mode and checks R8's actual mapping.txt output, which is a useful regression guard independent of how the keep rules are produced (catches R8 upgrades, jnigen bugs, or conflicting rules elsewhere in proguard-rules.pro).

Context

See #3972, which added this sync tooling.

[linear-code]

DART-455