Fix JWT authentication security issues

[ramonski]

Description of the issue/feature this PR addresses

Fixes three security-critical issues in the JWT PAS plugin introduced in #88.

Current behavior before PR

1. Anonymous DoS via unbounded keystorage writes. decode_token() called signing_secret(userid) on the verification path, which lazily wrote a new entry to the portal's OOBTree annotation for any userid an unauthenticated client put into a JWT userid claim. An attacker could spray tokens with random userids and force unbounded ZODB writes / ConflictError storms while never authenticating successfully.
2. Unsafe peek call. jwt.decode(token, verify=False) used the deprecated verify= kwarg (removed in PyJWT 2.x — pinning to pyjwt<2.0.0 masks it for now) and did not constrain the algorithm. A forged alg: none token reached the verification path before being rejected on signature mismatch.
3. Fragile Authorization header parsing. get_jwt_token() read request._auth (private API) and used auth.split()[-1] to extract the token, which silently picks the wrong segment when the header contains extra whitespace or unexpected components.

Desired behavior after PR is merged

1. signing_secret() is split. The create-on-miss path (signing_secret) is reachable only from create_token() (i.e. /login). The verification path (authenticateCredentials → decode_token → new get_signing_secret()) never mutates the keystorage. authenticateCredentials also looks up the claimed user via api.get_user() before reaching decode_token, so non-existent userids short-circuit immediately. An attacker submitting tokens with random userids causes zero ZODB writes.
2. peek_userid() now calls jwt.decode(token, options={"verify_signature": False}, algorithms=["HS256"]). The options form is supported by both PyJWT 1.x and 2.x, and the explicit algorithms list rejects alg: none tokens at the peek step.
3. get_jwt_token() uses the public request.getHeader("Authorization") API and auth[7:].strip() to extract the token after the Bearer prefix.

Tests

New doctest in bearer.rst asserts that a token claiming an unknown userid is rejected and leaves the keystorage untouched. Existing doctests (forged token, expired token, secret rotation, header/cookie/fallback extraction) continue to pass.

Run with:

bin/test test_doctests -t bearer
bin/test test_doctests -t login

--
I confirm I have tested the PR thoroughly and coded it according to PEP8 standards.

[xispa]

Excellent, thanks for fixing this vulnerability