takpacket-sdk 0.5.1 still bundled its own Wire-generated copies of the
TAK protos, which collide with org.meshtastic:protobufs:2.7.25
(checkReleaseDuplicateClasses: 'Duplicate class org.meshtastic.proto.*
found in protobufs-android and takpacket-sdk-jvm-0.5.1'). 0.5.3 stopped
bundling protos — consumers bring their own protobufs SDK — which is
exactly the alignment this PR exists for.

0.5.3 also dropped the SDK's iOS klib variants (it publishes JVM-only
artifacts now; the conversion pipeline is zstd-jni/xpp3-bound), so the
dependency moves from :core:model commonMain to jvmAndroidMain, and the
one direct commonMain reference (CotMeshSanitizer in TAKMeshIntegration)
now goes through a CotSanitizer expect/actual seam alongside the existing
TakSdkCompressor/TakV2Compressor seams: jvmAndroid delegates to the SDK,
iOS is a passthrough stub until Swift SDK interop lands.

With takpacket out of iOS dependency resolution entirely, the
iosMetadataConfigs exclude hack in build-logic (which papered over
0.5.1's missing iOS metadata JARs) is dead — removed.

Note: 0.5.3 was built with Kotlin 2.4.0, but JVM-only artifacts are fine
under 2.3.21 via the n+1 metadata rule — unlike native klibs (ABI-gated),
which is why mqtt-client stays at 0.3.6 until MQTTastic-Client-KMP#55
ships a 2.3.21-built 0.3.8.

Also tracks the flatpak platformDependencies compose-desktop pin to the
catalog version (1.11.1) — same fix as release/2.8.0 — so the offline
aarch64 flatpak verification can resolve desktop-jvm-linux-arm64 again
(pre-existing failure on main, surfaced here because this PR triggers
the verify-flatpak path filter).

Supersedes #5764.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>