NizKhata Android v1.11.4

Release builds are obfuscated, and CI proves it every time (#118)

The release build never passed --obfuscate, so the AOT snapshot shipped
with this repo's own source paths in it: screens/debt_detail.dart,
data/mutations.dart, data/permissions.dart, 78 of them. That is a map of
the data model and of the permission checks the client believes in, handed
to anyone who unzips the APK. It is the obvious starting point for probing
the Firestore rules for a gap the client happens to cover and the server
does not.

The build now runs with --obfuscate --split-debug-info=build/symbols.

A flag is easy to lose in a later edit and nothing would look wrong, so
the pipeline no longer takes it on trust. A step after the build unzips
the APKs, reads libapp.so, and greps it for this repo's own source paths,
read off the source tree at build time so the check cannot drift out of
step with it. Any hit fails the release and names the paths. Verified
both ways against a synthetic binary: it fails on one carrying the paths
and passes on one without.

The symbols are what makes an obfuscated stack trace readable again, so
they are kept as a build artifact for 90 days, keyed by commit. They are
deliberately NOT attached to the release: publishing them beside the APK
would hand back exactly what obfuscating it removed.

Worth being plain about the limit: this raises the cost of reading the
app, it is not a security boundary. The boundary is the Firestore rules,
which run on the server and have their own test matrix in CI. Obfuscation
buys time against someone mapping the app; it does not make a weak rule
strong.


Claude-Session: https://claude.ai/code/session_016jkAcgzuuxTfBiAgMLWgC4

Co-authored-by: Claude <noreply@anthropic.com>