Baixar jwtd 5.7.0 per a Windows

## A hardening release

Two code-base reviews since 5.6.0 turned up nineteen findings, and this release closes all of them. Nothing changes for well-formed tokens and keys; every fix tightens an edge where jwtd accepted something it should have refused, printed something it should not have, or reported a verdict it could not stand behind.

## Three of them mattered for verification

**An empty `oct` JWK was an empty HMAC secret.** jwtd rejects an empty symmetric secret because everyone knows it, but a JWK or JWK Set entry with `"k"：""` reached the verifier without passing that gate, so an HS256 token signed with the empty key reported `Signature: VALID`. Every JWK path now goes through the same check as `raw:` and `hmac:`, and the rejection names the key instead of falling through to a hint that would have suggested the JWK's own JSON as a secret.

**A non-string `kid` selected the first key in a JWK Set.** RFC 7515 requires `kid` to be a string. A header carrying `"kid"：123` or `"kid": null` was treated as if no `kid` were present, and a JWK Set then handed back its first entry without a word. It is now an error, on the human and `--json` paths and for JWEs alike.

**The signing-method allowlist fails closed.** An X25519 key parses as a valid JWE key but can verify no JWS. It used to skip the allowlist and rely on each `Verify` implementation's type assertion to refuse it; jwtd now refuses such a key itself before any verification runs.

## Claim validation no longer trusts a number it cannot represent

`--verify-claims` handed `exp`, `nbf`, and `iat` to the JWT library as raw numbers, and the library converts them through a float whose conversion error it discards. An `exp` of `1e400` therefore reported `token is expired`, and an `nbf` of `1e400` reported valid. Both now yield `Claims：INVALID` with a reason that names the claim and says the value is not a representable timestamp — the same rule the display already applied when it declined to annotate the value.

## `--key` reaches nested tokens

A decrypted JWE payload that is itself a JWE or JWT is decoded recursively, but the recursion dropped the key：the inner JWE printed its encrypted part sizes and asked for a key you had already passed, and the inner JWT printed without a signature verdict. The outer key is now applied at every level, and an invalid nested signature sets the exit code. When the key does not fit the inner token, jwtd falls back to the keyless rendering it produced before.

## Also in this release

• A `null` header or payload segment is rejected as `expected JSON object` instead of rendering as `{}` with a passing claim verdict.
• The human JWT path resolves the key before writing anything, as the JWE and `--json` paths already did, so an unusable `--key` yields the error alone rather than three decoded sections followed by one. A directory passed as `--key` says so instead of being read as base64 text.
• `jwtd ""` and an empty stdin pipe both report `no token provided`. Piped input is bounded at 16 MiB with an explicit error rather than a silent truncation.
• `--json --color=bogus` is rejected like the non-JSON path, and a JWE whose plaintext is the JSON literal `null` now emits `"decryptedPayload"：null` instead of omitting the field.
• The `expires in` / `not yet valid` annotations are computed from Unix seconds, so an `exp` more than 292 years away shows its real distance instead of the `106751d` at which `time.Duration` saturates.
• Encrypted part sizes are measured arithmetically from the base64url text instead of decoding the ciphertext to count it.

## What's Changed
• fix：close review findings on verification, flags, and output by @bsg62 in https://github.com/webcodr/jwtd/pull/31
• fix：close code-review findings on keys, claims, and output by @bsg62 in https://github.com/webcodr/jwtd/pull/32

**Full Changelog**：https://github.com/webcodr/jwtd/compare/v5.6.0...v5.7.0