Yes that’s correct, it should be nullable / optional in both the database in the server item.
I realise another problem though, which is if you update an existing client which has had encrypted notes from a newer client already synced with it, the encrypted notes would be in the wrong column in the sqlite db of the client which was upgraded and the new is_locally_encrypted column would initialise to null.
The proposal from the other candidate has gone down a slightly different path whereby there is no separate local_cipher_text column, but the cipher is stored in the body column with the prefix, and the fallback logic applies on loading the note. For that implementation, there would not be an issue if an old client with encrypted data from a new client is then upgraded. I think due to this migration issue, that this solution would actually be a better choice, otherwise you’ll then have to duplicate the fallback detection logic in Note load.
Note that for that solution, you do additionally need to suppress the beforeChangeItemJson explicitly when is_locally_encrypted is true, and you also have to opt out with the search indexing.