feat(codes): share scannable-code geometry via KMP; export tip codes as PNG/SVG

[bmc08gt]

Tip cards need PNG and SVG export. Rather than write that twice, the part that actually has to agree between platforms — where every mark goes — moves into a KMP module, and each platform keeps only a thin painter over it.

commonMain (KMP) native (thin)
────────────────────────────── ──────────────────────────
KikCodeGeometry.describe(size) ──┬───► Canvas drawCircle/drawArc → Bitmap → PNG
├───► CGContext (iOS, next) → UIImage → PNG
KikCodeSvg.render(...) ────┴───► just write the bytes (no painter)

Rasterisation stays native deliberately — Skiko/CMP would add several MB to the iOS framework to produce byte-identical PNGs nobody needs. Only the maths is shared, and the maths is the part that can drift.

:libs:codes:kikcode

Pure Kotlin, no platform APIs:

• KikCodeGeometry.describe(payload, dimension) → KikCodeDescription: the centre, badge well, dot diameter, and an ordered list of Dot / Arc / Ring marks. Runs of consecutive set bits collapse into a single stroked arc with round caps — geometrically the same union as per-bit dots plus connecting bands, with far fewer elements, which is what keeps the SVG small.
• KikCodeSvg.render(...) → a self-contained SVG document. Export is code-only (matching what the share preview already shows), so there is no text and therefore no font to embed.

Exported through :kmp:shared-core, so iOS picks it up in the SharedCore XCFramework.

Android becomes a painter, not a second implementation

KikCodeContentRendererImpl drops from 139 lines of fused maths-and-drawing to ~30 lines of draw calls. The on-screen view, the exported PNG, the exported SVG, and iOS now come off the same numbers.

TipCodeExporter writes either format to cacheDir/share_exports/ behind the existing FileProvider.

The parity gate

test-vectors/kikcode.json plus a golden SVG, produced by an independent Python implementation written from the spec ratios rather than transcribed from the Kotlin — so a match is corroboration, not a tautology. Both run on the JVM host and on Kotlin/Native.

The byte-for-byte SVG comparison is the one that earns its keep: Double.toString() is unspecified across Kotlin targets and libm cos/sin can differ in the last place, so every emitted number is fixed to 3 decimals via roundToLong() (ties toward positive infinity — the only tie-break Kotlin actually specifies).

Getting the native half to run at all needed a fix: Kotlin/Native test binaries ship no resource bundle, so NSBundle.pathForResource finds nothing and a resource-based loader silently only ever runs on the JVM. Fixtures are now compiled into commonTest as generated Kotlin, which works on every target and drops the expect/actual loader.

Five Robolectric tests cover what the vectors cannot reach — that arc sweeps aren't inverted, that the badge fills its well, and that the graphic frames correctly.

Worth a look on device

The on-screen code is ~4.2% larger. Android used to inset the graphic to 0.93 and then have KikCodeContentView overscan by 1.03 to compensate (a net 0.958); iOS just uses 0.5. This adopts iOS's canonical value so the export and the on-screen code can't disagree — but it's a visible change to the bill and tip card, and the badge well grows from 0.298 to 0.32 of the graphic to match iOS.

Follow-ups

• TipCodeExporter has no UI entry point yet — that lands with the new You tab design work.
• iOS consumption (swap KikCode.generateDescription for the exported geometry, add a CGContext painter) is a code-ios-app change.
• Noticed in passing: :libs:encryption:base58's iosTest has the same missing ExperimentalForeignApi opt-in, which means its Kotlin/Native vector test has never compiled. Its iOS parity runs through FlipcashCoreVectors instead, so coverage isn't actually missing, but the dead source is misleading.