Repository clone is over 1 GB due to generated binaries in history

A fresh clone is much larger than the current source tree:

- checkout: about 1.1 GB
- `.git`: about 1.0 GB
- current files outside `.git`: about 50 MB

Most of the Git data appears to come from old generated mobile binaries, including:

- `flutter/android/jniLibs.zip` (about 100 MB per revision)
- Android `libcactus*.so` files (about 40–45 MB per revision)
- `cactus.xcframework.zip` files (about 15 MB per revision)

Could these generated archives be kept out of Git and published through releases or CI artifacts instead?

Adding ignore rules can prevent the repository from growing again. Reducing the existing clone size would also require a maintainer-coordinated history rewrite, since deleting files in a new commit does not remove their old blobs.

Start by auditing the repository history and the named artifacts: flutter/android/jniLibs.zip, Android libcactus*.so files, and cactus.xcframework.zip files. Check the existing release and CI artifact workflows before proposing where generated binaries should be published. Done means future generated binaries are excluded from Git and a maintainer-approved history rewrite plan addresses existing blobs.

Written by the indexing model from the issue text.