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, but there was no source for the keys tied to this project itself.
This adds one.

The signing key rotated between 0.7.1 and 0.8.0, so both keys are needed to verify the
full set of published releases.

• 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.

Key	Signs
7ED4 A780 3AFC 6DE8 47DF 9A3F 70EE 73F2 1701 2D0E	0.8.0 and later
20FF 0D66 B2D0 202C 1544 7339 7E77 F31E 27A4 AEA2	0.3.0 through 0.7.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 11 published duo-client versions (0.3.0 → 0.8.0) verify against these two
  keys and no others. 0.3.0–0.7.1 report Good signature ... [expired]
  (EXPKEYSIG — key expired after the signature was made, which is expected);
  0.8.0 reports Good signature (GOODSIG).
• Non-jar artifacts for 0.8.0 also verify (.pom, -sources.jar, -src.tar.gz,
  -cyclonedx.json), confirming the README's claim that signatures accompany each
  artifact.
• Keys cross-checked against independent fetches from keyserver.ubuntu.com and
  keys.openpgp.org — identical fingerprints and identical canonical export.
• Header dates derived from the key packets, and version ranges 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.
• Confirmed KEYS does not enter any published artifact — the src assembly's
  fileSet resolves to the module basedir, not the repo root (checked against the
  real published duo-client-0.8.0-src.tar.gz).

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