refactor: Replace Hutool-based JWT generation with RSA (RS256) and add user token authentication in im-gateway

[dennis9486]

Title

Replace Hutool-based JWT generation with RSA (RS256) and add user token authentication in im-gateway

Summary

Stop using Hutool to generate JWTs. Standardize on RSA (RS256) using a vetted JWT library (implemented in a shared jwt-util module). Also enforce token authentication in im-gateway for HTTP and WebSocket handshakes; reject unauthorized requests.

Requirements (key points)

• Token signing/generation must use RSA (RS256). Private key only for signing; public key used for verification and can be published via JWK or a controlled endpoint for gateways/services.
• All services must stop using Hutool to generate tokens. (Hutool verification fallback during migration is allowed briefly but should be removed ASAP.)
• im-gateway must validate tokens at HTTP (Authorization: Bearer) and WebSocket handshake stages; invalid or expired tokens are rejected (HTTP 401 / WS handshake refused).
• Keys (private/public) must be stored in KMS/Vault. Do not commit keys to repo in plaintext.

Acceptance Criteria

• Tokens are signed with RS256 and include standard claims (iss, sub, aud, iat, exp) plus necessary custom claims (e.g. userId, roles, sessionId).
• im-gateway intercepts and rejects HTTP/WS requests that are missing or carry invalid tokens.
• Documentation published: token issuance/verification flow, key rotation procedure, and how clients should send tokens.
• Unit and integration tests cover token generation, verification, expiry and tampering scenarios.

Tasks

• Add or update jwt-util in platform/common repo (implement RS256 using jjwt / java-jwt / nimbus or similar).
• Replace all Hutool token generation call sites across services (start with im-auth, publish new version).
• Implement auth middleware/filter in im-gateway for HTTP and WebSocket handshake verification; add logging and metrics for verification.
• Support smooth migration: gateway should prefer new tokens and allow configurable fallback to old tokens for a short grace period.
• Write ops doc: where to store private keys, key rotation steps, and rollback procedures.

Migration Plan (brief)

1. Publish jwt-util (RS256 implementation) and enable new issuance in im-auth in canary.
2. Update im-gateway to validate new tokens (enable compatibility switch).
3. Migrate other token issuers to the new implementation; monitor usage of old tokens.
4. After grace period, disable compatibility switch and remove Hutool-related code.
5. Perform key rotation and verify logs/alerts.

Please assign and proceed: jwt-util → im-auth → im-gateway → remaining services.