[kmitchel]

What

GET and POST /Items/{itemId}/PlaybackInfo now accept a recording ID returned by /LiveTv/Recordings. A client can negotiate playback using the DVR ID even before the recording has a scanned library item.

Upgrade note: None.

Why

Ferrofin stores recordings separately from library items. The recording stream routes already resolve DVR IDs, but PlaybackInfo returned 404 at the library lookup before it asked the media source manager. Jellyfin v12.4 uses library item IDs for recordings. See MediaInfoController and LiveTvController.

How

Keep the existing library lookup first. For a DVR ID, share the streaming routes' Live TV and recording visibility checks, then use the existing DVR source lookup by ID. Hidden library items remain hidden, and unrelated IDs still return 404. The access-filtering parity record describes the DVR ID fallback.

The change touches the API playback and stream authorization paths. Successful library lookups avoid the DVR fallback. Routes and storage schema are unchanged.

Verification

• Formatting and diff whitespace checks passed.
• The server's recording visibility regression now covers both PlaybackInfo methods with an unscanned DVR ID, including source selection, library restrictions, channel visibility, and disabled Live TV access. All 31 tests in the server item visibility suite passed on Arch Linux.

Checklist

• Conventional Commit and DCO sign-off.
• cargo fmt --all --check.
• Jellyfin v12.4 comparison and access-filtering parity update.
• Performance scope described above.
• Server item visibility suite (31 tests).
• Remaining workspace checks and live HTTP verification.