[Discussion] Cross-platform foundations: consider architecture choices that don't foreclose an Android port

Congratulations on getting this to a public proof of concept, the local-first approach and the decision to put the data pipeline in Rust are both good calls, and I think the project has real potential. I'd like to raise a discussion point about the current architecture as it relates to a possible Android port in the future. I'm not suggesting an immediate rewrite, that would be unreasonable at alpha stage, but I think a few conscious decisions made now could avoid expensive rework later. --- **What's already in good shape** The most important thing here is the Rust core. Because the app routes all packet processing through `Rust/core` via a JSON-over-C bridge (`goose_core_bridge.h`), the heaviest lifting is already in a language that compiles cleanly to Android targets (`aarch64-linux-android`, `armv7-linux-androideabi`, and others). That work is not wasted on an Android port — it's directly reusable. The clean separation between the Swift shell and the Rust core is also encouraging. It suggests the UI and the data pipeline are not deeply entangled, which is exactly the right foundation for a future port. --- **Things worth deciding consciously now** **1. Treat the C bridge ABI as a stable contract** If `goose_core_bridge.h` is documented and kept stable, it becomes the interface any future Android port (whether Kotlin/JNI or Flutter/Dart FFI) would consume. The same header works across both approaches. A small amount of attention to this now avoids the Rust crate gro...