chore(deps): collapse duplicated majors and move off unmaintained lines

[otavio]

What

Collapsed four dependencies that were linked into the binaries at two majors
at once, and moved two unmaintained ones to their current line: golang-jwt to
v5, go-redis to v9, Masterminds/semver to v3, plus alignment of the agent's
gliderlabs/ssh and docker requirements with the rest of the workspace.

Why

Each of these had the same shape: the codebase already depended on the newer
major somewhere, so both were compiled in. The server signed web-terminal
tokens with golang-jwt v5 while pkg/api/jwttoken and LoadKeys stayed on
v4; asynq pulled in redis/go-redis/v9 while the cache wrapper still used the
archived go-redis/redis/v8. Two copies of a JWT or Redis client in one binary
is a latent source of type mismatches and duplicated connection pools, and the
v8/v1 lines no longer receive fixes.

Changes

• golang-jwt v4 → v5: pkg/api/jwttoken and server/api/services/utils.go
  (LoadKeys). RegisteredClaims, NewNumericDate and ParseWithClaims
  behave the same in v5, so this is an import path rewrite; v5 is now the only
  JWT library in the tree.
• go-redis v8 → v9: pkg/cache/cache_redis.go and go-redis/cache/v8 →
  /v9. The wrapper only uses ParseURL, NewClient, SetNX and cache's
  Item, all unchanged.
• Masterminds/semver v1 → v3: agent and server. v1 predates modules and is
  unmaintained; the API we use (NewVersion, MustParse, LessThan,
  GreaterThan, Original, String) is identical.
• agent module alignment: the agent required gliderlabs/ssh v0.3.5 against
  the server's v0.3.8. The shared replace made the requirement inert today,
  but it decides the resolved version the moment that replace goes away.
• tests module: pinned to the same docker commit the agent uses for the
  CVE-2026-34040 backport (the test module was still on v28.5.2), and retidied
  after the JWT bump.

Testing

The JWT change is the one worth probing: tokens minted before this branch must
still parse, so check login and web-terminal auth against an existing session
rather than only a fresh one. The Redis change is exercised by the cache tests,
which run against a real Redis via testcontainers.

The matching cloud change is shellhub-io/cloud#2475 — cloud's replace
points at this branch, so CI there resolves against it.

[github-actions]

Claude finished @otavio's task in 2m 4s —— View job

---

Code Review Complete

Reviewed 20 files across code quality, security, testing, language patterns, and architecture — no new issues found. The code looks good as-is.

This is a clean, mechanical dependency consolidation. I verified each migration against the actual call sites rather than only the diff:

• golang-jwt v4 → v5 (pkg/api/jwttoken, server/api/services/utils.go): every API used — RegisteredClaims, NewNumericDate, ParseWithClaims, NewWithClaims, WithValidMethods, Keyfunc, SigningMethodRS256 — is signature- and behavior-compatible in v5. Device tokens with no ExpiresAt remain valid (v5 keeps exp optional), so pre-branch tokens still parse.
• go-redis v8 → v9 + cache v8 → v9 (pkg/cache/cache_redis.go): ParseURL, NewClient, SetNX(...).Result(), and cache Item/ErrCacheMiss are unchanged.
• Masterminds/semver v1 → v3 (agent + server): NewVersion, MustParse, LessThan, and new(semver.Version) all compile and behave the same for the simple versions compared here.
• go.mod / go.sum consistency: no leftover jwt/v4, redis/v8, cache/v8, or semver (v1) imports anywhere in the tree; redis/go-redis/v9 correctly promoted to a direct dependency; golang-jwt/v4 fully removed; go.uber.org/atomic added as an indirect dep of go-redis/cache/v9.

One operational note for the deploy (not a code defect, no change requested): go-redis v9 negotiates RESP3 by default, whereas v8 spoke RESP2. This is transparent for Redis ≥ 6.0 but worth keeping in mind if any target environment still runs Redis 5.x.

To request another review round, comment /review.