Fix - stale recording overlay

[WizardOfYendor1]

When you press up on the remote (overlay) when watching livetv then press the record button, the button doesn't change state (e.g. doesn't change red). You have to leave the menu then come back to see if it's recording. Same is true if you cancel the recording.

On a side note, there are psuedo related issues with #5396 and jellyfin/jellyfin#16191.... (which is why I keep peeling the onion :-) ). You would need 16191 or live in a + UTC to even be able to press record in the first place from the overlay. Once I could do that (-5 UTC here), I noticed all these other problems and started at least trying to fix them.

Changes
Change to update the "items" list dynamically so the user doesn't have to exit and come back to get a refresh.
The "big" change was to making the items list mutable on the setter call.

Opus 4.6 was used to check potential impacts it the "ecosystem" and research tasks. There were none noted.

[WizardOfYendor1]

This fix it part of the myriad of PRs I have out there dealing with the display overlay.

I apologize for how scatterbrained it may be but I'd fix one thing only discover that it exposed another issue. Fix that and so forth and so one.

I have merged them all up into an integration branch I have in my fork that I use to build and test them (on a Fire Cube). Seems to be behaving and working. It's definitely no worse for me.

[nielsvanvelzen]

The mItems should be read-only. We cannot change it unless we replace all items, which cannot be done during playback.

[WizardOfYendor1]

The mItems should be read-only. We cannot change it unless we replace all items, which cannot be done during playback.

Hmmmm... OK. I'm curious as to what problem that creates but I'll take your word for it. Oddly, I was trying a different approach that I thought was uglier I'll see if I can get that working and make mItems immutable again.

[WizardOfYendor1]

I've made changes to restore mItems to being immutable again. I used sorta a "shadow object" accomplish the same effect. There maybe a better approach.

I detected another issue as noted in the subsequent commit that is related. This one is, to me, more straight forward.

Lastly, there are issues surrounding recording a series, cancelling a series, then recording the series again. Issues that have existed before any of this. This is what I consider an edge case (i.e. unrealistic), as I'm blasting through testing stuff. I've got some preliminary analysis but I think it's going to involve issues with the server side. It's a deeper rabbit hole, I don't have time to address right now.

If there is better approaches, or changes, I will not be offended if the maintainers wish to make them in-situ of these commits/PR(s) :-)