chore(crypto): use node v24 supported encryption format

[ajohn25]

Description

This PR moves Spoke to the cryptography methods that are supported in node v24

Motivation and Context

Prep for merging #88 - node v24 deprecates the previous "easier" crypto methods

This PR focuses on messaging_service.encrypted_auth_token as the only stored value which is encrypted via the changed functions.

Note that campaign.previewUrl is also generated via the same encryption function. However, since that value isn't stored, we don't need to really worry about a migration for it. Clients who use preview URLs often will notice that the format for the URL (ex. always including a colon), as well as old links, have changed.

How Has This Been Tested?

This has been tested locally by:

1. Loading in a client session secret to .env + adding their messaging service record to the local database
2. Running dev-tools/symmetric-decrypt.js with the encrypted_auth_token string and storing this (to verify against in step 4)
3. Switching to this branch and running the new migration (to encrypt the token with an iv)
4. Running dev-tools/symmetric-decrypt.js with the newly encrypted value to verify that the decrypted string matches the one from step 2

Release Notes

• build!: upgrade to v24 LTS #88 must be on a separate release to be rolled out after a release that contains this
• We should create an easy to restore backup of messaging_service records, prior to rolling this out, just in case

Screenshots (if appropriate):

Documentation Changes

Checklist:

• My change requires a change to the documentation.
• I have included updates for the documentation accordingly.

[ajohn25]

Notes on Claude recs above:

❗ Add backward compatibility to symmetricDecrypt for preview URLs (Critical)
This actually isn't possible because symmetricDecrypt is deprecated in node v24 😞

❗ Add error handling to migration (High)
❗ Add null/empty token filtering to up migration (High)
This isn't strictly necessary because we would have bigger problems if prod messaging_service records didn't have valid tokens, but added cause why not 😝 Performance isn't an issue since the messaging_service table is small (max couple dozen rows with current instances)

[sukhada]

@ajohn25 thanks for the detailed response and explanations, and also for sharing the graphile migration opinions. I had somewhat surmised the importance of keeping migration code constant, so I was trying to minimize the chances of code change by using helper functions with a V2 suffix in the name (and maybe comments to not edit) to reduce the chance of change. The only con that I can see with code reuse is the potential for some accidental minor difference. I think tests (once we have a more developed test suite) would be a great way to minimize this to not rely solely on manual testing. Having said all that, I am leaning towards your version, just sharing my thoughts!

[ajohn25]

The only con that I can see with code reuse is the potential for some accidental minor difference. I think tests (once we have a more developed test suite) would be a great way to minimize this to not rely solely on manual testing. Having said all that, I am leaning towards your version, just sharing my thoughts!

@sukhada agreed 😅 I'll go ahead and tweak to work in your #2 suggestion about calling this method V2 for now then!