nLogin integration does not register premium and Bedrock auto-login players #64

Description

When nLogin premium auto-login is enabled, premium players bypass the
/register command. AzLink currently only listens to nLogin's
RegisterEvent, so these players are never created in Azuriom.

The same problem may affect Bedrock players authenticated through
BedrockLoginEvent.

This prevents those players from using Shop guest purchases because the
Shop username login requires the player to already exist in Azuriom's
users table.

Environment

• Azuriom: 1.2.12
• AzLink: 1.3.13
• nLogin: 2.0.19
• Platform: BungeeCord-compatible proxy (NullCordX)
• Java: 22
• Shop guest purchases: enabled
• Premium auto-login: enabled

Steps to reproduce

1. Enable premium auto-login in nLogin.
2. Use a premium player that does not already exist in Azuriom.
3. Join the server.
4. nLogin authenticates the player automatically without /register.
5. Check the Azuriom users table or try Shop guest login with that username.

Current behavior

The player is not created in Azuriom because
NLoginIntegration only handles RegisterEvent.

Non-premium players that execute /register are synchronized correctly.

Expected behavior

A player successfully authenticated through PremiumLoginEvent should be
created or updated in Azuriom using:

• Minecraft username
• verified UUID
• IP address
• nullable email
• no password, allowing Azuriom to generate a random password

BedrockLoginEvent should probably use the same flow.

Suggested implementation

• Listen to PremiumLoginEvent and optionally BedrockLoginEvent.
• Add a registration method that supports a missing password.
• Do not send the password JSON property when it is null, so Azuriom can
  generate a random password.
• Make registration idempotent by UUID/game_id because premium login events
  may be fired on every connection.
• Apply the behavior consistently to Bukkit, BungeeCord and Velocity
  integrations.

A companion change may be needed in Azuriom's register endpoint. It currently
validates name and game_id as unique before checking whether a user with
that game_id already exists, so the existing update branch appears
unreachable for already synchronized players.