[Android JCA] Design Android JCA backend opt-in and packaging

[mfazrinizar]

Problem

The android-jca-branch imports impl_jni whenever dart.library.ffi is true, so JNI replaces FFI on Android and desktop native targets. Independently, hook/build.dart builds and registers libwebcrypto.so for every code-asset target. A JCA test build therefore still packages this package's BoringSSL library.

The core package:webcrypto pubspec does not require Flutter. package:jni 1.0.0 requires Flutter 3.35.6 or newer and registers platform plugins, so keeping JNI in the core dependency graph would change which applications can depend on package:webcrypto.

Runtime registration and native-asset packaging need separate controls. Registering a Dart backend cannot stop the build hook from packaging libwebcrypto.so; the build must know whether the application selected a JCA-only Android configuration.

Draft PR #326 changes native linking and adds BoringSSL symbol tree shaking. If it lands, measure whether a JCA-only build still emits a native asset instead of treating symbol removal as asset omission.

Candidate Package Split

• Put the JNI/JCA implementation and package:jni dependency in a companion package:webcrypto_jca package.
• Expose a supported backend interface and registration hook from package:webcrypto.
• Require each isolate to register the JCA backend before its first Web Crypto operation.
• Add an explicit Android build setting that tells the webcrypto build hook when it may omit libwebcrypto.so.
• Keep PBKDF2 feat(impl_jni): add JCA PBKDF2 implementation #357 unchanged until this design establishes whether a helper or FFI fallback can ship.

Maintainers still need to decide whether to use this package split.

Decisions Needed

• Decide whether JNI belongs in package:webcrypto or a Flutter-only companion package.
• Decide whether the prototype may use version-locked private package:webcrypto/src/... imports, or whether package:webcrypto must expose a supported backend interface and registration hook first.
• Define registration, repeated-registration, and per-isolate behavior.
• Choose the build setting, such as a build-hook user define, that permits omission of libwebcrypto.so only for an Android JCA build.
• Define how the build confirms that the companion package is present before it omits BoringSSL, and how runtime reports missing registration.
• Decide whether JCA opt-in must exclude FFI or may keep an FFI fallback for PBKDF2.

Validation Required

• Add build-hook tests for the default build, Android JCA opt-in, invalid setting values, and non-Android targets.
• Compare release APK/AAB contents and size with the default FFI build.
• Repeat the native-asset check with feat: add link hook for treeshaking native symbols via record_use #326 if its link-hook changes land first.
• Test initialization, repeated registration, and independent isolate registration.
• Verify that live JCA key wrappers remain isolate-unsendable.
• Run the complete shared Android TestRunner through the public opt-in path.

Related: #296, #326, #357