Fiber jwtware: should expired JWTs return a distinct 401 for refresh, and what are the limits of built-in expiry handling?

I'm designing authentication for a Fiber (v2) API using the contrib jwtware middleware and need to settle how expired credentials behave before I lock in the client contract. From the documentation, jwtware validates the signature and time claims and rejects an expired token with a 401 before it reaches my handler, and the ErrorHandler hook lets me customize that rejection.

My goal is least-privilege scoping: public routes stay unauthenticated, sensitive route groups get role/scope checks reading claims from c.Locals(). The open decision is the expiry path. I can either return a distinct 401 body or error code so clients trigger a token refresh flow, or treat expiry identically to an invalid token and force re-login. Fiber appears to leave this entirely to the application.

I'm also unsure how reliably I can distinguish 'expired' from 'malformed' inside ErrorHandler, since the wrapped error type seems to depend on the underlying JWT library version, and whether session middleware expiry (lazy, on read) changes anything if I mix both mechanisms.

Is returning a machine-readable 'token_expired' code from ErrorHandler a sound pattern, or does it leak useful signal to attackers? Are there documented limits on what ErrorHandler can safely assume about the validation error across jwtware versions? Should refresh tokens live in Fiber's session store or a separate mechanism?