[Bug] SEA.decrypt fails to decrypt the output of SEA.encrypt where the encrypted data is a malformed JSON string

[nsreed]

When I encrypt then decrypt the value "[hello there]" (a string), I expect both the value and the type of the decrypted value to match that of the input. Instead, the decrypted value becomes [] (an empty array). See example below:

    const data = `[hello there]`;
    const pair = await SEA.pair();
    const enc = await SEA.encrypt(data, pair);
    const dec = await SEA.decrypt(enc, pair);
    console.log(`dec matches data? ${dec === data}`);
    console.log(`data is ${data}`);
    console.log(`typeof data is ${typeof data}`);
    console.log(`dec is ${dec}`);
    console.log(`JSON.stringify(dec) is ${JSON.stringify(dec)}`);
    console.log(`typeof dec is ${typeof dec}`);
    console.log(`Array.isArray(dec) is ${Array.isArray(dec)}`);

outputs

dec matches data? false
data is [hello there]
typeof data is string
dec is 
JSON.stringify(dec) is []
typeof dec is object
Array.isArray(dec) is true

This is similarly an issue for other types when they appear in strings, where I am expecting the type and value of SEA.decrypt() to match the input to SEA.encrypt(). If it's a string going in, I expect a string with identical contents coming out, since that is the behavior for other input types. Issue #1188 was trying to address this problem, but the example was too specific and the workaround necessitated encapsulating raw strings in an object, will not help me recover existing encrypted values with these characteristics.

I have an assortment of encrypted strings that happen to look like JSON, which were actually user text input, and now I'm unclear on how/if they can be decrypted as raw strings.

As for a resolution? I'd settle for adding something like skipParse to an optional options argument in SEA.decrypt as to not break backwards compatibility? Or updating the API and TS docs to mention this behavior if it is intended/unfixable.