Publish a debug APK as a GitHub Release so anyone can try this without building it

[NITISH-R-G]

Objective

Attach a signed or debug APK to a GitHub Release on tag push, so a judge, reviewer, or curious stranger can install and try the app without cloning the repo and running a Gradle build.

Rationale

Flagged repeatedly in the audit: today there is no way to experience this product except by building it from source, which is a five-minute-minimum barrier that kills every discoverability and first-impression path (Product Hunt, a shared link, a judge trying it between pitches). CI already builds and uploads the debug APK as a workflow artifact - artifacts expire and require a GitHub login to download; a Release does neither.

Acceptance criteria

• Pushing a tag matching v* triggers a workflow that builds assembleDebug (or a signed release build, if signing is set up) and attaches the APK to a GitHub Release
• The release notes template includes the required manual setup steps (grant overlay/mic/accessibility, add a Sarvam key or run keyless) since this app cannot be a single-tap Play Store install
• No signing key or keystore password is ever committed - if release signing is added, the keystore must come from a GitHub Actions secret, following the same discipline as the Sarvam key

Implementation steps

1. Add a release.yml workflow triggered on push: tags: ['v*']
2. Reuse the existing assembleDebug step from android.yml (or add assembleRelease if signing is configured separately - that's a bigger decision, flag it explicitly rather than bundling it into this issue)
3. Use softprops/action-gh-release (or equivalent) to attach the APK and populate release notes from a template
4. Tag the current main and confirm the release appears with a working, installable APK attached

Estimated effort

Low (half a day - this is almost entirely CI configuration, not application code)

Risks

• A debug-signed APK cannot be a Play Store artifact and some devices warn heavily on "unknown sources" installs - this is a stopgap for reviewers/judges, not a distribution strategy, and the release notes should say so explicitly rather than imply otherwise
• If release signing is added later, keystore handling needs the same secret-scanning discipline already in place for the Sarvam key (see SECURITY.md)

Testing checklist

• Tag a test version, confirm the workflow runs and a Release appears with the APK attached
• Install the attached APK on a clean device (not the one used for development) and confirm it launches
• Confirm the release notes accurately describe the manual setup required