fix(security): UserService::createApiToken — reject invalid expiresIn

`parseExpiration()` returns `null` for any string that doesn't match
the `^(\d+)([dhm])$` regex (e.g. "5x", "abc", "90 days"). The caller
wrote that null straight into the persisted token row, where a null
`expires` means a *non-expiring* token. Net effect: a typo in the
expiration mints a permanent API key instead of producing an error.

Throw `\InvalidArgumentException` from the controller surface when the
input is supplied but unparseable. Existing "no expiration provided"
path (`$expiresIn === null` or empty) still produces a non-expiring
token — that's an explicit operator choice, not a malformed-input
side effect.

Refs: #1419 review (off-diff blocker — top-level comment 4378205122)

Author: rubenvdlinde

lib/Service/UserService.php

@@ -1231,9 +1231,18 @@ public function createApiToken(IUser $user, string $name, ?string $expiresIn=nul
         $tokenId    = $this->secureRandom->generate(16);
 
         // Calculate expiration.
+        // SECURITY: a non-matching `expiresIn` (e.g. "5x", "abc") used to
+        // fall through to `$expires = null` → non-expiring token. That is
+        // a perpetual API key minted from malformed input. Reject the
+        // request instead so the caller sees the typo.
         $expires = null;
         if ($expiresIn !== null && $expiresIn !== '') {
             $expires = $this->parseExpiration(expiresIn: $expiresIn);
+            if ($expires === null) {
+                throw new \InvalidArgumentException(
+                    'Invalid expiresIn value "'.$expiresIn.'" — expected a number followed by d (days), h (hours), or m (minutes), e.g. "90d".'
+                );
+            }
         }
 
         $now       = date('c');