fix(build): scope JitPack to its own coordinate namespaces

[bmc08gt]

Five Dependabot PRs (#1352, #1353, #1354, #1355, #1356) went red within the same five-minute window, all with the same configuration-phase failure:

> Could not resolve org.gradle:gradle-tooling-api:5.2.1
  Required by: buildscript of root project 'Flipcash'
               > com.ahasbini.tools:android-opencv-gradle-plugin:0.1.3-dev
  > Could not GET 'https://jitpack.io/org/gradle/gradle-tooling-api/5.2.1/gradle-tooling-api-5.2.1.pom'
     > Read timed out

Nothing was compiled and no test ran, so those PRs got no signal on the bumps they were meant to exercise.

Why a JitPack blip breaks an unrelated artifact

gradle-tooling-api:5.2.1 is published only to repo.gradle.org/gradle/libs-releases, which the buildscript already declares:

Repository	gradle-tooling-api:5.2.1
dl.google.com	404
repo1.maven.org	404
plugins.gradle.org/m2	404
jitpack.io	timed out
repo.gradle.org/gradle/libs-releases	200

The problem is ordering. JitPack sits ahead of repo.gradle.org, so it is queried for every artifact, and a read timeout aborts resolution rather than falling through to the next repository the way a 404 does. Resolution never reaches the repository that has the artifact.

retries=0 in gradle-wrapper.properties is unrelated here. It only covers the wrapper distribution download.

The change

All three JitPack declarations (root buildscript, pluginManagement, dependencyResolutionManagement) are restricted to the com.github, com.gitlab and com.bitbucket namespaces JitPack serves, so Gradle no longer makes a network call to JitPack for anything else.

Nothing in the build resolves from JitPack today. The OpenCV plugin, which looked like the obvious JitPack consumer, resolves from gradlePluginPortal and 404s on JitPack. Every other non-Central group resolves from Central, Google or maven.fpregistry.io. Removing the repository outright would also work, but filtering keeps a future JitPack-style dependency working without putting JitPack in the resolution path of everything else.

No resolved version changes. Both checks below ran with --refresh-dependencies, so the answers came from the network rather than the local cache:

• ./gradlew buildEnvironment --refresh-dependencies resolves com.ahasbini.tools:android-opencv-gradle-plugin:0.1.3-dev -> org.gradle:gradle-tooling-api:5.2.1, the exact path that was failing.
• ./gradlew :apps:flipcash:app:dependencies --configuration debugRuntimeClasspath --refresh-dependencies succeeds with no FAILED markers, including for the non-Central groups dev.theolm, dev.bmcreations, com.fingerprint.android, com.ionspin.kotlin and org.kin.sdk.android.

A JitPack outage can no longer fail a build that does not depend on JitPack.