Remove -dontoptimize from Amazon consumer ProGuard rules

[tsushanth]

Why

feature/amazon/consumer-rules.pro contains a -dontoptimize directive that disables R8/ProGuard optimization globally for any app that depends on the Amazon billing feature. This causes the entire consuming app to skip optimization, not just the Amazon SDK classes — silently inflating APK size and degrading runtime performance for all customers using the Amazon appstore variant.

The rule was almost certainly a defensive copy-paste from Amazon's own SDK documentation, which advises it for their internal SDK. It is not needed for the RevenueCat wrapper and has no documented justification in the file.

What changes

Remove the -dontoptimize line from feature/amazon/consumer-rules.pro. The remaining rules (-dontwarn, -keep class com.amazon.**, -keepattributes *Annotation*) are unaffected and continue to prevent stripping of Amazon SDK reflection targets.

Validation

R8 optimization is now re-enabled for the Amazon feature module's consumers. The existing -keep class com.amazon.** {*;} rule still prevents any Amazon SDK class from being removed or renamed, so there is no regression risk for Amazon IAP calls. No logic in the RevenueCat codebase relies on optimization being disabled.

Fixes #3496

---

Note

Low Risk
Single-line ProGuard consumer rule change with Amazon SDK classes still fully kept; no runtime logic changes.

Overview
Removes -dontoptimize from feature/amazon/consumer-rules.pro, so apps that depend on the Amazon billing feature no longer inherit a rule that turned off R8/ProGuard optimization for the whole app.

-dontwarn, -keep class com.amazon.**, and -keepattributes *Annotation* are unchanged and still protect Amazon SDK classes from stripping/renaming.

^{Reviewed by Cursor Bugbot for commit 7b22faf. Bugbot is set up for automated code reviews on this repo. Configure here.}

[tonidero]

Hi @tsushanth, thanks for your contribution! While we agree this is far less than ideal, we need to make sure this is valid since Amazon actually recommends adding this to the proguard files: https://developer.amazon.com/docs/in-app-purchasing/iap-obfuscate-the-code.html

In any case, we agree this is not ideal specially in hybrid SDKs where using amazon is optional and we should split up the amazon module so it only affects folks using it.

[tsushanth]

Thanks for the context, @tonidero! I understand — Amazon does officially recommend -dontoptimize in their IAP obfuscation docs for their SDK internals, so removing it outright without validation isn't straightforward.

The split-module approach sounds like the right long-term fix: scoping the rule to only consumers who actually pull in the Amazon IAP integration avoids the blanket performance penalty for everyone else while still respecting Amazon's recommendation for those who need it. Happy to close this PR and wait for that refactor if that's the direction you're taking, or help with any part of it if useful. Let me know how you'd like to proceed.