docs(agents): Refresh new_module rule and cover full system-test runs

Validating the previous commit with agents surfaced two gaps.

`new_module.mdc` had drifted from the repo. Its README badge snippet still
used the retired maven-badges.herokuapp.com format, while every current row
in README.md uses shields.io with a central.sonatype.com link. It also never
mentioned four steps that every existing integration module performs: the
`SENTRY_*_SDK_NAME` constant in `Config.kt` consumed by buildConfig and the
jar manifest, the `libs.versions.toml` entry paired with a `compileOnly`
dependency, self-registration via `SentryIntegrationPackageStorage.addPackage`
and `addIntegrationToSdkVersion`, and the integrations dropdown in the issue
template. It now also points at `sentry-kafka` and `sentry-android-timber` as
build-script templates, and records that `sentry-bom` and the root build file
need no change because they iterate over subprojects.

The `test` skill only ever ran a single module, so folding the AGENTS.md
testing block into it dropped the only reference to running the whole system
test suite. Step 3b now covers `make systemTest` and `make systemTestInteractive`.

Author: runningcode

.claude/skills/test/SKILL.md

@@ -78,6 +78,14 @@ test -d .venv || make setupPython
 
 This starts the mock Sentry server, starts the sample app (Spring Boot/Tomcat/CLI), runs tests via `./gradlew :sentry-samples:<sample-module>:systemTest`, and cleans up afterwards.
 
+To run **every** system test instead of one module, use the Makefile targets — they also create the
+venv for you:
+
+```bash
+make systemTest             # all system tests (--all)
+make systemTestInteractive  # pick the setups to run (--interactive)
+```
+
 ## Step 4: Report Results
 
 Summarize the test outcome:

.cursor/rules/new_module.mdc

@@ -12,7 +12,9 @@ This document outlines the complete process for adding a new module to the sentr
 
 ### 1. Create the Module Structure
 
-1. Create the new module, conforming to the existing naming conventions and build scripts
+1. Create the new module, conforming to the existing naming conventions and build scripts.
+   Copy the `build.gradle.kts` of the closest existing integration rather than writing one from
+   scratch — `sentry-kafka` is a good JVM template, `sentry-android-timber` a good Android one.
 
 2. Add the module to the include list in `settings.gradle.kts`
 
@@ -27,9 +29,36 @@ ignoredProjects.addAll(
 )
 ```
 
-3. If adding a JVM sample, add E2E (system) tests, following the structure we have in the existing JVM examples.
+3. Add a `SENTRY_{MODULE}_SDK_NAME` constant to the `Config.Sentry` block in
+   `buildSrc/src/main/java/Config.kt`:
+
+```kotlin
+val SENTRY_FOO_SDK_NAME = "$SENTRY_JAVA_SDK_NAME.foo"
+```
+
+The module's `build.gradle.kts` consumes it in both `buildConfig` and the jar manifest
+(`Sentry-SDK-Name` / `Sentry-SDK-Package-Name`) — see `sentry-kafka/build.gradle.kts`.
+
+4. Add the instrumented library to `gradle/libs.versions.toml` and depend on it with
+   `compileOnly(libs.<lib>)`, so the integration does not force the dependency on users.
+
+5. Register the integration with the SDK so it is reported in the `sdk` payload. Every
+   integration does this — see `sentry-openfeature/.../SentryOpenFeatureHook.java`:
+
+```java
+static {
+  SentryIntegrationPackageStorage.getInstance()
+      .addPackage("maven:io.sentry:sentry-{module-name}", BuildConfig.VERSION_NAME);
+}
+// then, from the constructor:
+addIntegrationToSdkVersion("{IntegrationName}");
+```
+
+6. If adding a JVM sample, add E2E (system) tests, following the structure we have in the existing JVM examples.
    The test should then be added to `test/system-test-runner.py` and `.github/workflows/system-tests-backend.yml`.
 
+`sentry-bom` and the root `build.gradle.kts` need no change — they iterate over subprojects.
+
 ### 2. Create Module Documentation
 
 Create a `README.md` in the module directory with the following structure:
@@ -46,22 +75,29 @@ The following tasks are required only when adding a module that isn't a sample.
 
 ### 3. Update Main README.md
 
-Add the new module to the packages table in the main `README.md` with a placeholder link to the badge:
+Add the new module to the packages table in the main `README.md`. Copy the row of a neighbouring
+module and swap the name — Android modules carry a third column for the min API level, JVM modules
+do not:
 
 ```markdown
-| sentry-{module-name} | [![Maven Central](https://maven-badges.herokuapp.com/maven-central/io.sentry/sentry-{module-name}/badge.svg)](https://maven-badges.herokuapp.com/maven-central/io.sentry/sentry-{module-name}) | |
+| sentry-{module-name} | [![Maven Central Version](https://img.shields.io/maven-central/v/io.sentry/sentry-{module-name}?style=for-the-badge&logo=sentry&color=green)](https://central.sonatype.com/artifact/io.sentry/sentry-{module-name}) |
 ```
 
 Note that the badge will only work after the module is released to Maven Central.
 
-### 4. Add Documentation to docs.sentry.io
+### 4. Add the Module to the Issue Template
+
+Add `- sentry-{module-name}` to the integrations dropdown in
+`.github/ISSUE_TEMPLATE/bug_report_java.yml`, or `bug_report_android.yml` for an Android module.
+
+### 5. Add Documentation to docs.sentry.io
 
 Add the necessary documentation to [docs.sentry.io](https://docs.sentry.io):
 - For Java modules: Add to Java platform docs, usually in integrations section
 - For Android modules: Add to Android platform docs, usually in integrations section
 - Include installation instructions, configuration options, and usage examples
 
-### 5. Post release tasks
+### 6. Post release tasks
 
 Remind the user to perform the following tasks after the module is merged and released: