feat(logback): add posthog-server-logback appender module

[cat-ph]

🚨 Before merge / release

posthog-server-logback is not wired into the release workflow. The version-sync step and the publish matrix in .github/workflows still need an entry for the new module (and the module needs its Sonatype coordinates confirmed). That was deliberately left out of this PR — no workflow files are touched here — so the repo owner can wire it up. Merging as-is is safe: nothing publishes the module yet.

💡 Motivation and Context

Fourth and last PR in the JVM error-tracking stack: a new posthog-server-logback module (com.posthog:posthog-server-logback, 0.1.0) with a Logback appender that reports logged errors to PostHog Error Tracking through the server SDK.

• PostHogAppender (AppenderBase<ILoggingEvent>, package com.posthog.server.logback) captures events at or above minimumCaptureLevel (default ERROR) that carry a Throwable, sending them through the server SDK's captureException so request-context distinct-id resolution and in-app frame config apply automatically (the appender runs on the logging thread, inside any active PostHogRequestContext scope).
• Wiring: register a client you already configure with PostHogAppender.setPostHog(client) once at startup (events logged before registration are dropped — documented), or let the appender self-configure from logback.xml via <apiKey>/<host>, in which case it owns and closes that client on stop(). An explicitly registered client always wins.
• Events from com.posthog… loggers are always skipped (recursion guard), events without a throwable are skipped (no message-only synthesis in this first version), and captured events carry $exception_level, logger_name, and log_message when the log message differs from the throwable message.
• Uses the PostHogCapturedThrowables guard from PR 3, so an exception already reported by the uncaught handler is not re-reported when a log mirror sees the same instance.
• Build wiring is additive: settings.gradle.kts, pnpm-workspace.yaml, gradle.properties (serverLogbackVersion=0.1.0), Makefile dry/release targets, and a LOGBACK version constant in buildSrc. Logback is compileOnly (consumers bring logback-classic; the 1.3.x line is the last one targeting Java 8), and posthog-server is an api dependency.

The module is explicitly pre-1.0: the changeset says the public API may change between minor versions.

💚 How did you test it?

• New PostHogAppenderTest (8 tests): an error with a throwable becomes exactly one $exception event with the expected properties, below-threshold events ignored, WARN captured with warning level once the threshold is lowered, com.posthog logger names skipped for recursion, a logger merely sharing that string prefix still captured, throwable-less events ignored, events logged before a client is registered dropped, and the same throwable instance logged twice captured once.
• ./gradlew :posthog-server-logback:test :posthog-server-logback:apiCheck pass; spotlessCheck clean. The module's gradle.lockfile was regenerated so it matches the repo's current kover/animalsniffer versions.
• Not covered here: publishing. See the note at the top.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran pnpm changeset to generate a changeset file
• Added the "release" label to the PR to indicate we're publishing new versions for the affected packages

🔗 Stacked PR

Position 4 of 4 (top of the stack). Base: cat/java-et-uncaught (PR #671).

1. PR feat(error-tracking): complete exception chain metadata and in-app classification #669 — core exception chain metadata + in-app classification
2. PR feat(server): expose in-app frame config and captureException options #670 — server error-tracking config and captureException options
3. PR feat(server): opt-in uncaught exception capture #671 — opt-in server uncaught-exception capture
4. this PR — new posthog-server-logback appender module

[github-actions]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.

[github-actions]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week.