build(store): manage Play listing via fastlane supply

[haritabh17]

What

The Play listing becomes code. store-assets/ content moves into the fastlane convention tree and supply now uploads it on every deploy:

android/fastlane/metadata/android/en-US/
├── title.txt                    Featherwork: Badminton Drills (29 chars)
├── short_description.txt        (77 chars)
├── full_description.txt         exact copy of the live listing
├── changelogs/22.txt            What's new for the current release
├── changelogs/default.txt       fallback when a versionCode has no file
└── images/
    ├── icon.png                 512×512
    ├── featureGraphic.png       1024×500
    ├── phoneScreenshots/        5 framed shots, 1080×1920
    ├── sevenInchScreenshots/    3 shots, 800×1244
    └── tenInchScreenshots/      3 shots, 1202×1540

• Fastfile: the four skip_upload_* flags flip to false — every tag deploy re-asserts title, descriptions, graphics, screenshots and the changelog.
• AGENTS.md: release ritual now includes writing changelogs/<versionCode>.txt at bump time, and the rule that listing edits happen by PR, never in the console (the next deploy would revert them).

Why

• Listing copy and screenshots get the same review→merge→deploy discipline as code — no more console field-pasting, no drift between repo and store.
• This is the F-Droid-compatible convention used across open-source Android apps.

Notes

• All text is byte-for-byte what's live on the listing today, so the first deploy after merge is a no-op re-assert (it still passes through Play's listing review — normal, non-blocking).
• Kept out on purpose: raw/ intermediates and the promo MP4s (video belongs on YouTube; video.txt can carry the URL once it's uploaded).
• Local store-assets/ stays as the untracked working folder for producing future shots.