feat(rails): forward Rails.logger to PostHog Logs via OpenTelemetry

[johnnagro]

💡 Motivation and Context

Adds an opt-in integration that forwards Rails.logger output to PostHog Logs
(https://posthog.com/docs/logs) over OpenTelemetry/OTLP, automatically correlated
with the request's distinct_id and session_id captured by the existing
request-context middleware.
The OpenTelemetry gems are optional/soft dependencies loaded lazily, so the
feature no-ops with a single warning when absent (and on Ruby < 3.3 where the
logs SDK is unsupported). The logs token and host are derived from the configured
client (config.api_key / config.host) with ENV fallbacks, so logs always
target the same project as analytics. Disabled by default; enabled via
PostHog::Rails.config.logs_enabled.

💚 How did you test it?

• Unit specs for the appender, setup (gems present/absent + token/host resolution),
  and railtie broadcast wiring (full suite green on Ruby 3.2.2, rubocop clean).
• End-to-end in an ephemeral rails new app against a real PostHog project:
  Rails.logger output appears in PostHog Logs.

📝 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.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
posthog-rails/lib/posthog/rails/logs/setup.rb:136-140
The `service.version` OTel resource attribute is being set to `PostHog::VERSION`, which is the SDK/integration gem version — not the Rails application's version. Per OpenTelemetry semantic conventions, `service.version` represents the deployed application version, so this would cause every service to report the PostHog gem version as its "version" in PostHog Logs. Consider using `telemetry.sdk.version` for the SDK version instead, and omitting `service.version` from the defaults (users can supply it via `logs_resource_attributes`).

```suggestion
            attrs = {
              'service.name' => service_name,
              'telemetry.sdk.name' => 'posthog-rails',
              'telemetry.sdk.version' => PostHog::VERSION,
              'deployment.environment' => ::Rails.env.to_s
            }
```

### Issue 2 of 2
spec/posthog/rails/logs/appender_spec.rb:40-46
Non-parametric severity tests per project convention — `Severity::MAPPING` defines 6 entries (DEBUG→5, INFO→9, WARN→13, ERROR→17, FATAL→21, UNKNOWN→9) but only INFO and ERROR are verified. An RSpec `using` table (e.g., a `described_class` parametric approach with `let`/`subject` per row, or a shared example loop over `MAPPING`) would cover all cases with no duplication and catch a mapping regression for WARN, FATAL, or the UNKNOWN→INFO fallback.

_{Reviews (1): Last reviewed commit: "feat(rails): forward Rails.logger to Pos..." | Re-trigger Greptile}

[turnipdabeets]

Cc @PostHog/logs