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.

Jellyfin.Plugin.ShareLinks/PluginServiceRegistrator.cs

@@ -3,6 +3,7 @@ using Jellyfin.Plugin.ShareLinks.Services;
 using Jellyfin.Plugin.ShareLinks.Storage;
 using Jellyfin.Plugin.ShareLinks.Web;
 using MediaBrowser.Controller;
+using MediaBrowser.Controller.Authentication;
 using MediaBrowser.Controller.Plugins;
 using Microsoft.Extensions.DependencyInjection;
 
@@ -24,6 +25,7 @@ public class PluginServiceRegistrator : IPluginServiceRegistrator
         serviceCollection.AddSingleton<ShareTokenService>();
         serviceCollection.AddSingleton<ItemTagService>();
         serviceCollection.AddSingleton<JellyfinGuestUserService>();
+        serviceCollection.AddSingleton<IAuthenticationProvider, GuestAuthenticationProvider>();
         serviceCollection.AddSingleton<ShareLinkCreationService>();
         serviceCollection.AddSingleton<ShareLinkRedemptionService>();
         serviceCollection.AddSingleton<ShareLinkCleanupService>();