fix: guard refresh token claim extraction against panic

[mrofreP]

controllers/authentication.go:361-362 read the refresh_uuid and user_id
claims from a validated refresh token via unchecked type assertions:

refreshUUID := claims["refresh_uuid"].(string)
userID := int32(claims["user_id"].(float64))

A refresh token that passes signature verification but is missing
either claim, or carries the wrong type on either claim, panics on
the type assertion. middleware.Recover translates the panic into an
HTTP 500 rather than the intended 401 -- same class of bug as the
ConfirmManagerChange token slicing fix.

Reachable scenarios:

• A legitimate refresh token issued by an older schema of the API.
• A JWT from a different service that happens to share the refresh
  signing key.
• Any operator-crafted token used during debugging or migration.

Replace the assertions with ", ok" checks that return a clean 401
("Invalid refresh token") and log a warning naming the missing/wrong
claim, so operators see the real reason in logs instead of a
recovered panic stack.

Add TestAuthenticationController_RefreshToken/malformed_refresh_token_
claims_should_return_401 with four subtests (missing refresh_uuid,
missing user_id, refresh_uuid wrong type, user_id wrong type). Each
signs a well-formed token with the real refresh secret and asserts
401 + "Invalid refresh token" body -- the pre-fix code would surface
these as 500s.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}