call Jellyfin's APIs directly instead of probing for them at runtime

JellyfinGuestUserService looked up IUserManager methods by reflection, trying
eight candidate signatures for ChangePassword alone, and ItemTagService did the
same for UpdateItemAsync. That fails at runtime on any API drift and only logs a
warning, which is exactly how the DbUpdateConcurrencyException hunt started. We
already pin Jellyfin.Controller 10.11, so these are now plain typed calls and any
future drift is a compile error. 427 lines of shim gone, behaviour unchanged
(UpdateItemAsync still gets ItemUpdateType.None, password still set before the
policy update).

Guest accounts also get their own authentication provider now, which refuses every
interactive sign-in. Redemption is unaffected: AuthenticateDirect passes
enforcePassword false and never consults a provider. If the plugin is disabled the
provider id stops resolving and Jellyfin assigns the account to its own
InvalidAuthProvider, which refuses too, so this fails closed. A random password is
still set as a second line of defence.

README.md

@@ -107,7 +107,10 @@ on the server, using Jellyfin's own session manager. No password is ever stored
 anywhere, not even encrypted, and no password ever appears in the page sent to
 the guest. The only thing the guest's browser receives is a session token
 scoped to that one guest account, and that token dies the moment the guest
-account is cleaned up.
+account is cleaned up. On top of that, the guest account is assigned an authentication provider that
+refuses every interactive sign-in, so the normal login page cannot be used to get
+into a guest account at all, password or not. If the plugin is disabled Jellyfin
+falls back to its own invalid-provider handling, which refuses too.
 
 ## Configuration