fix(encryption): improve setKey robustness (better checks/throws)

[joshtrichards]

• Resolves: #

Summary

• Ensures setKey throws on encoding, encryption, or write failure
• Adds explicit check for partial file writes by comparing bytes written to expected length
• Refines error handling for maximum cryptographic key safety
• Drops dead code (<= v21)
• Also refactors getKey() for clarity (dropping dead code, flattening conditionals, simplified migration logic, type hinting)

Context:

The setKey() function is the underlying basis for all the set*Key() functions. It's extremely important for data integrity. While it can in theory return false for failures, in reality almost no callers (direct or indirect) actually check the return value (nor would they necessarily know what to do with a false/failure since it's inherently catastrophic).

This change maintains the API contract (boolean -- though only true is realistically returned) while utilizing exceptions for all catastrophic errors (and they're all catastrophic).

In additional to generally being wise, this may surface the causes of weird issues that sometimes get reported with keys.

TODO

• Consider using ServerNotAvailableException like getKey() though that seems just as generic

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)