fix(types): expose namespace decorator types

[abdulmunimjemal]

Refs #348.

Problem

The FastifyJwtNamespace<T> helper currently maps the namespaced
decorators (<ns>JwtSign, <ns>JwtVerify, <ns>JwtDecode) to
JWT['sign'], JWT['verify'] and JWT['decode']. Those types describe
the synchronous fastify.jwt.* instance methods, which take an explicit
token argument and return a value directly.

The decorators that actually end up on FastifyRequest/FastifyReply
have different signatures:

• reply.jwtSign(...) is asynchronous and returns Promise<string>.
• request.jwtVerify(...) and request.jwtDecode(...) extract the
  token from the request, so they do not take a token argument.

As a result, users following the namespace docs
either get incorrect IntelliSense or have to hand-roll the augmentation
themselves to call request.accessTokenVerify() or
reply.accessTokenSign(payload).

Fix

• Extract the existing request/reply decorator overloads into reusable
  JwtSignFunction, JwtVerifyFunction and JwtDecodeFunction
  interfaces.
• Use those interfaces for the default FastifyReply.jwtSign,
  FastifyRequest.jwtVerify and FastifyRequest.jwtDecode
  declarations, so there is a single source of truth.
• Map FastifyJwtNamespace entries to those interfaces, so consumers
  using the namespace/jwtDecode/jwtSign/jwtVerify registration
  options get correctly typed decorators on FastifyRequest and
  FastifyReply.

This is a types-only change. No runtime code is touched.

Tests

types/index.tst.ts:

• Existing FastifyJwtNamespace assertions updated to expect the new
  function types instead of the JWT instance method types.
• Added negative assertions confirming the new decorator types are
  intentionally distinct from the JWT instance method types.
• Added a small end-to-end example that augments FastifyInstance,
  FastifyRequest and FastifyReply with accessToken* decorators
  (the exact scenario from Type augmentation for namespace methods? #348) and verifies the decorators are
  callable without a token argument and return the expected payload
  type.

npm test passes: 175 unit tests, 100% coverage, 34 type assertions.

Checklist

• run npm run test
• tests are included
• documentation is changed or added
• commit message and code follows the Developer's Certificate of Origin and the Code of Conduct

[mcollina]

lgtm