Add KEYS file with Maven signing public keys

[mihir-pradhan]

Summary

Release artifacts on Maven Central are signed, and the public keys have been published
to public keyservers. #60 asks for a way to confirm that the key used to sign a release
is one this project intends — that is, a source for the keys tied to the project itself.
Raised after the signing key rotated between 1.3.1 and 1.3.2.

• Adds a KEYS file at the repo root with both signing keys.
• Adds a ## Verifying releases section to the README with the verification commands
  and a version → fingerprint table.
• Fixes the LICENSE badge, which pointed at the old master branch.

Key	Signs
7ED4 A780 3AFC 6DE8 47DF 9A3F 70EE 73F2 1701 2D0E	1.3.2 and later
20FF 0D66 B2D0 202C 1544 7339 7E77 F31E 27A4 AEA2	1.0.2 through 1.3.1 (expired 2026-01-27)

The file contains public key material only. Trust derives from commit access: whoever
can change this file can change the code it signs.

The retired key is retained so signatures made while it was valid remain verifiable.
The file is append-only by design — deleting a key would break verification of
already-published releases.

How Has This Been Tested?

• gpg --import KEYS → 2 keys imported, 0 secret keys, no PRIVATE KEY markers
• All 9 published duo-universal-sdk versions (1.0.2 → 1.3.2) verify against
  these two keys and no others. 1.0.2–1.3.1 report Good signature ... [expired]
  (EXPKEYSIG — key expired after the signature was made, which is expected);
  1.3.2 reports Good signature (GOODSIG).
• Keys cross-checked against independent fetches from keyserver.ubuntu.com and
  keys.openpgp.org — identical fingerprints and identical canonical export.
• Header dates and version ranges derived from the key packets and from the signing
  key IDs on the .jar.asc files, not hand-entered.
• Fingerprint text matches gpg --fingerprint output character-for-character.
• The README command sequence and the Developers: append command in KEYS both
  run verbatim.

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Release management

Refs #60