Prepare the v3.3.0 release

[anakinj]

The version was bumped to 3.3.0 in #729, so what is left before tagging is the changelog and the upgrade notes.

Changelog

Dates the v3.3.0 entry and drops the "Your contribution here" placeholder. The entries themselves were already complete: everything merged since v3.2.0 that is not listed is spec-only or CI-only and ships nothing.

Upgrade notes for #722

3.3.0 is the release that carries the error hierarchy revamp, and the UPGRADING entry for it described the new classes first and reached the one incompatibility last, under a heading opening with "This is the part that can break". That is a poor summary of a change that needs no action from almost anyone upgrading.

It now opens with Backwards compatibility, stating the outcome first: the classes were inserted above the existing ones rather than replacing them, so every error class an application already rescues keeps its name, its meaning and everything it used to catch. The exception is then given as three conditions that must all hold:

1. The rescue is around JWT.encode, not JWT.decode.
2. It names JWT::DecodeError, JWT::IncorrectAlgorithm, JWT::UnsupportedEcdsaCurve or ArgumentError.
3. It is reachable at all, which takes a key or algorithm that cannot sign in the first place.

The third condition earns its place. Searching public code for the affected shape turned up a single project matching the first two, and it still needed a specific odd key before the rescue was reached at all — a secp256k1 key used with ES256, which slips past its own bit-length guard. It is capped at jwt < 3.0 and so cannot reach this release regardless, but it shows that clearing the first two conditions is not the end of the check.

A Why this is a minor release section explains the version choice, since a page arguing that a change is backwards compatible invites the question of why it is not a major one. Nothing here turns a call that used to succeed into one that fails or the reverse, so what moved is which rescue clause matches on a path that was already failing. It asks for an issue if anyone finds otherwise, which would be a bug rather than an intended consequence.

Also calls out the decode-side change from an escaping NoMethodError to a JWT::VerificationKeyError as catching more rather than less, so the compatibility claim stays honest.

Documentation only, no code changes.