feat: Refactor secret values

[stevehipwell]

Resolves #ISSUE_NUMBER

---

Before the change?

• Secret value naming was confusing
• Encrypted secret value didn't require key_id to be passed in

After the change?

• Secret value naming is consistent (value & value_encrypted)
• Secret value names ready for value_wo pattern
• value_encrypted requires key_id to be passed in

Pull request checklist

• Schema migrations have been created if needed (example)
• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[github-actions]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[deiga]

Changing the migration test input state doesn't seem correct, could you verify?

[stevehipwell]

@robert-crandall please could you give this a review?

[robert-crandall]

Before this PR, key_id had ConflictsWith: ["plaintext_value"], meaning key_id + encrypted_value was an explicitly documented (and valid) pattern. The docs said: "This should be provided when setting encrypted_value".

After this PR, key_id gains RequiredWith: ["value_encrypted"]. This means: if key_id is set in config, value_encrypted must also be set. Any user who currently has key_id = "..." alongside encrypted_value = "..." will get a plan-time validation failure immediately on upgrading, despite encrypted_value being nominally "deprecated but still supported."

The fix is either:

• Remove RequiredWith from key_id (users relying on deprecated encrypted_value + key_id shouldn't be broken), or
• Add "encrypted_value" to the RequiredWith list: RequiredWith: []string{"value_encrypted", "encrypted_value"} (so both old and new usage pass), or
• At minimum, document this as a breaking migration requirement with clear upgrade instructions.

[stevehipwell]

@robert-crandall the analysis you've got above is muddled, Copilot I assume? I added the key_id and made it conflict with plaintext_value when I fixed the secrets. I wanted to make it required for encrypted_value, as technically it is and without it the value could be un-decryptable, but that would have been a breaking change. This PR add the NEW value_encrypted and made key_id required when this is used. No changes outside of the deprecation for the old fields.