chore: Bump app version to 0.2.0

[bbaarriiss]

Bump the Github App version to 0.2.0

[claude]

Review: chore: Bump app version to 0.2.0

Verdict: LGTM — a one-line version = "0.1.0" → "0.2.0" change in build.gradle.kts:14. It matches the precedent set by #140 (also a single-file bump), and a minor bump is the right semver call given #147 added JVM/usage metrics (additive feature, no breaking change).

Nothing to flag on bugs, performance, security, or test coverage — the string isn't read at runtime, and I confirmed there are no other 0.1.0 occurrences anywhere in the repo (grep -rn "0\.1\.0" outside .git/build returns nothing), so nothing goes stale as a result of this change.

Observations (non-blocking, for a follow-up if useful)

1. The Gradle version is currently inert — nothing consumes it.
Tracing where it could flow, it's dropped at every step:

• build.gradle.kts:103 — archiveFileName.set("github-app.jar") pins the filename, so the version never reaches the artifact name (this is intentional; Dockerfile:9 copies that exact path, so please don't change it in isolation).
• .github/workflows/staging.yml — the image is tagged type=sha,format=short only, so published images carry no semver tag.
• helm/githubapp/values-prod.yaml:4 — tag: "sha-9efe83d", again sha-pinned.
• No src/main/**/*.kt references a version.

So this bump is documentation-only today. That's fine and worth doing, but it means the number can silently drift from what's deployed. Two cheap ways to give it teeth:

// build.gradle.kts, in the shadowJar manifest block (~line 104)
manifest {
    attributes["Main-Class"] = "com.wire.github.ApplicationKt"
    attributes["Implementation-Version"] = project.version
}

…which then lets you surface it at runtime (log line on startup, or on the existing health/metrics surface) so you can tell which build is actually running in staging/prod. Adding a type=semver tag alongside type=sha in the metadata action would give the same benefit at the image level.

2. helm/githubapp/Chart.yaml appVersion is still "0.0.1".
appVersion is meant to track the shipped application version, so it's now two bumps behind. Chart version: 0.0.1 is separate (chart packaging) and correctly independent, but the appVersion drift is real and will only widen. Not this PR's job to fix if the team treats the chart as sha-pinned by policy — but if so, it may be clearer to drop appVersion than to leave a wrong value.

3. No tag / CHANGELOG accompanies the bump.
The repo has no git tags at all, so 0.2.0 isn't anchored to a commit. If the intent is that this version is meaningful to consumers, a v0.2.0 tag (or a release) at merge time makes it findable. If it's purely internal bookkeeping, ignore this.

Not verified

I did not run ./gradlew build for this change — it alters only a metadata string with no other references, so a build run wouldn't exercise anything the PR touches. CI on the PR covers it.