fix(jellycompat): report the actual transcode target resolution/bitrate to admin sessions

[rangoDJ]

Summary

• Fixes jellycompat sessions show source resolution/bitrate instead of actual transcode target in admin panel #920: the admin sessions panel showed the source's resolution/bitrate instead of the actual transcode target for any Jellyfin-compatible (jellycompat) playback session being transcoded — including a MaxStreamingBitrate-capped downscale from fix(jellycompat): honor MaxStreamingBitrate cap in PlaybackInfo negotiation #912.
• SetTranscodeStreamDetails recorded video/audio codec, hw accel, and tone-map mode on the upstream session, but never TargetResolution/TargetBitrateKbps — only the native (non-compat) playback path threaded those through. The admin view falls back to displaying the source's own resolution/bitrate whenever target_resolution is unset for a transcoding session.
• recordTranscodeStreamDetails now forwards opts.TargetResolution and opts.TargetBitrateKbps through the extended setter, so session sync and the admin activity views reflect what ffmpeg is actually doing.
• Cosmetic/observability only — the real encode was never affected, only what the admin panel reported about it.

AI disclosure: This PR was developed with AI assistance (Claude).

Test plan

• TestSetTranscodeStreamDetails (extended) — verifies TargetResolution/TargetBitrateKbps are recorded.
• TestRecordTranscodeStreamDetailsIncludesTargetResolutionAndBitrate (new) — verifies the jellycompat handler forwards both fields through to the upstream session.
• gofmt -l clean on all touched files.
• go build/go test ./internal/playback/... locally.
• go test ./internal/jellycompat/... (CI).
• Verified live: deployed a temporary branch combining this fix with fix(jellycompat): honor MaxStreamingBitrate cap in PlaybackInfo negotiation #912's MaxStreamingBitrate cap (main alone has no code path that sets a non-empty target resolution/bitrate to forward, so fix(jellycompat): honor MaxStreamingBitrate cap in PlaybackInfo negotiation #912 was needed to produce something real to report), confirmed the admin sessions API showed the correct capped target_resolution/target_bitrate_kbps instead of falling back to the source's.

[coderabbitai]

Warning

Review limit reached

Next included review available in 2 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 2 included reviews currently available.

This review ran on the open-source allowance, not this organization's plan, because the pull request author doesn't have an assigned seat. Waiting won't change this — ask an organization admin to assign them a seat, or add seats in Billing if every seat is already assigned, then retry.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 1563e2a4-dc6f-4ce2-9ca4-d4fff5b8e045

📥 Commits

Reviewing files that changed from the base of the PR and between e767788 and 0311c74.

📒 Files selected for processing (5)

• internal/jellycompat/audio_selection_test.go
• internal/jellycompat/handlers_playback.go
• internal/jellycompat/remote_transcode_reconstruct_test.go
• internal/playback/recipecard_test.go
• internal/playback/session.go

---

_{Comment @coderabbitai help to get the list of available commands.}

[rangoDJ]

All checks pass. Live verification: main alone has no code path that sets a non-empty TargetResolution/TargetBitrateKbps for jellycompat's local transcode start (only the VideoToolbox tone-map path does, which isn't reachable on this Linux/QSV test host), so there was nothing capped to report without #912. I deployed a temporary branch combining this fix with #912 to a real server + Jellyfin Android client, capped a stream to 420 kbps, and confirmed the admin sessions API now correctly reports target_resolution: "480p", target_bitrate_kbps: 420 — matching the real ffmpeg command — instead of falling back to the source's 1080p/uncapped values.

Also worth noting from that same testing session: selecting different quality tiers in the Jellyfin Android app and comparing the resulting dashboard resolution against Jellyfin's own canonical bitrate→resolution table (jellyfin-web's qualityOptions.js) showed the dashboard is reporting correctly per Jellyfin's own reference semantics in every case checked (e.g. 8 Mbps → 1080p, 3 Mbps → 720p, 720 kbps → 480p) — the Android app's on-screen quality labels just don't match Jellyfin's own internal maxHeight for those same bitrate values. That's a labeling quirk in the Jellyfin Android client, not something actionable here.