CI on pull requests from forks always fails: the release pipeline runs without secrets

Describe the bug

The only workflow that runs on pull_request is android.yml ("Build release APK (FOSS)"). A PR from a fork fails every time, after 15 to 20 minutes, at the same step:

> Task :androidApp:uploadSentryProguardMappingsRelease FAILED
sentry reported an error: Invalid token header. No credentials provided. (http status: 401)

GitHub does not pass repository secrets to workflows triggered by fork PRs, so SENTRY_AUTH_TOKEN is empty. Two examples: run 31429423642 (#2328) and run 32866973365 (#2348). Of the 19 open PRs today, 4 have a green check, 1 failed, 1 cancelled, 12 have no check at all. In practice the check says nothing about whether a PR compiles, so it has to be verified by hand.

Cause

android.yml is the signed release pipeline: it writes isFullBuild=true to gradle.properties unconditionally, expects SENTRY_DSN/SENTRY_AUTH_TOKEN/LASTFM_* in local.properties, runs assembleRelease with the Sentry mapping upload as a finalizer, then signs with SIGNING_KEY/ALIAS/KEY_STORE_PASSWORD/KEY_PASSWORD. None of that can work on a fork PR. Fixing only the Sentry step would move the failure to the signing step.

Two side notes from reading the config: the workflow name says FOSS but isFullBuild=true is always written, and ignoredFlavors.set(setOf("foss")) in androidApp/build.gradle.kts refers to a flavor that does not exist (the FOSS/full split is done by swapping modules, not by product flavors).

Proposed fix

Separate "does the PR compile" from "publish a signed build":

1. New .github/workflows/pr-check.yml on pull_request, no secrets:
   • ./gradlew androidApp:assembleDebug (Android compiles; the debug build type is in ignoredBuildTypes of the Sentry plugin, so no upload, and debug signing needs no keystore)
   • ./gradlew desktopApp:jvmMainClasses (Desktop compiles)
   • ./gradlew domain:allTests plus the other modules that have JVM tests
2. android.yml keeps push and workflow_dispatch only.

A green check would then mean: compiles on Android and Desktop, JVM tests pass. Same setup as today (JDK 21, submodules: recursive).

I can open the PR if you want it. If you prefer to keep a single workflow, the alternative is if: conditions on the Sentry, signing and upload steps, but then green means different things for internal and fork PRs.

Start with .github/workflows/android.yml and compare its triggers, secret-dependent steps, and JDK 21 setup with the proposed pull_request checks. Read androidApp/build.gradle.kts for the Sentry plugin configuration, then run the listed Gradle Android, desktop, and JVM test commands without secrets. Done means fork pull requests receive a meaningful green or failing compile/test check while signed release publishing remains available for pushes and manual runs.