set and edit don't encrypt new keys when combined with (un)encrypted-regex

If a .sops.yaml file exists and specifies an encrypted regexp (or unencrypted regexp), and you add a key that should be encrypted to a file using sops or sops --set, the config is ignored and the new key will not be encrypted.

This is a bit dangerous, as a couple of obvious flows to adding a secret to a config file are:

1. Add the key to the sops config file to specify it should be encrypted

2. either:

   a. run something like sops -i --set "['newsecret'] \"$(head -c 32 /dev/urandom | base64)\"" myfile.yaml

   b. use sops myfile.yaml to edit interactively

If you don't double-check the file, you will think you have an encrypted secret in there and actually you have a plaintext secret.

The workaround I've found is to use one of the above methods to add the secret, then decrypt and encrypt it in place, i.e. sops -d -i file.yaml && sops -e -i file.yaml

Start by reproducing the issue with a .sops.yaml encrypted or unencrypted regexp, then compare sops --set and interactive sops editing of a new key. Trace how each flow applies the configuration and verify that newly added keys follow the configured regexp instead of remaining plaintext.