chore: WPB-29049 Bump JVM SDK version to 0.3.0

[bbaarriiss]

Bump JVM SDK version to 0.3.0

[claude]

Review — chore: WPB-29049 Bump JVM SDK version to 0.3.0

Scope is a single-line change in build.gradle.kts:24, moving com.wire:wire-apps-jvm-sdk from 0.3.0-beta to the GA 0.3.0. Moving off a pre-release onto a stable tag is the right call, and no call sites needed touching. 👍

Code quality / conventions: Nothing to flag. The version is inline like every other dependency in the file, so it is consistent with the existing style, and 0.3.0-beta was the only pre-release pin in the build — after this, all dependencies are on stable versions. README.md references the SDK only by link, not by version, so there is nothing else to keep in sync.

Verification: I could not resolve artifacts or run the build in this environment, so the items below are things to confirm from the CI run rather than defects I observed.

1. API compatibility beta → GA. The app binds to a non-trivial slice of the SDK surface — WireAppSdk (routing/EventRoutes.kt:28, including the cryptographyStorageKey/apiToken/apiHost constructor shape), WireEventsHandlerSuspending overrides, WireApplicationManager, WireMessage, QualifiedId, Conversation/ConversationMember, and WireException. ./gradlew build in pull-request.yml compiles and runs the test suite, so a signature break would surface there; worth a glance at the green check before merging rather than assuming beta and GA are identical.

2. Persistent crypto/MLS state is the real risk here, and CI cannot see it. The Helm chart mounts a PVC at /app/storage (helm/pollapp/templates/statefulset.yaml:77) and the SDK is handed cryptographyStorageKey derived from CRYPTO_PASSWORD. If the GA release changed the on-disk keystore schema or key derivation versus the beta, an in-place rollout against an existing volume could fail at startup or lose MLS group state — and because this is a StatefulSet with a single PVC, rollback is not automatically clean either. Please check the SDK release notes for any storage migration, and ideally validate the upgrade on staging against a volume that already carries beta-era state (not a fresh one) before promoting to prod.

3. Behavioural changes under a same-number GA. 0.3.0-beta → 0.3.0 reads like "no change but the label", but betas sometimes diverge from their GA counterpart in defaults (retry/backoff, event delivery semantics, message encoding). A skim of the changelog between the two tags would be enough to rule this out.

Performance: No impact from the change itself; any difference is whatever the SDK brings with it.

Security: Positive on balance — leaving a pre-release build for a released one means picking up any fixes made during stabilisation. No new dependencies and no new transitive surface are introduced by this diff. (Unrelated to this PR, but since the build has no dependency locking or verification: if the team ever wants reproducibility guarantees on these bumps, Gradle dependency locking or a version catalog would be the place to add it — not something to block on here.)

Test coverage: No new tests are warranted for a version bump; the existing suite under src/test/kotlin exercising the services and parser is the right regression signal, and CI runs it. Item 2 above is the gap the test suite structurally cannot cover, so a staging soak is the substitute.

Nothing blocking from my side — happy to see this merge once CI is green and the storage-compatibility question in item 2 has an answer.