Did only the first part since I don't want to tell people with more WebAssembly experience than me how to interface with it...

I think my previous suggested text is reasonable. We also probably want to add something like:
Utilities like wasm-bindgen are often used to automate WebAssembly function binding generation and may rely on Web classes like TextEncoder and TextDecoder to accomplish these conversions. We can supply implementations of these classes using encodeUtf8() and decodeUtf8() like so:

class TextEncoder { encode(s) { return protectedAudience.encodeUtf8(s); } }
class TextDecoder { decode(s) { return protectedAudience.decodeUtf8(s); } }

We should probably include links to wasm-bindgen and TextEncoder and TextDecoder.

I think my previous suggested text is reasonable.

Memory array isn't the only way.
https://developer.mozilla.org/en-US/docs/WebAssembly/Guides/JavaScript_builtins

(And your polyfill example lacks feature detection --- and is too modern a JS dialect for me to check by eyeballing)

Memory array isn't the only way.

I think I covered that by proposing "may rely on..."

JS builtins seem like they might allow calling built-in JS functions on JS Strings from WASM, but I don't think they allow WASM to efficiently access the characters of the string.
I'm not saying my proposed text is perfect, feel free to edit and improve it, but I think we need to provide more help to readers in using these new additions and I think we need to explain the motivation for these. Explainers' central responsibility is to discuss motivation.

It has a "charCode at index X" builtin, but I have no idea of how fast it is; and also how well it fits the tooling on the other side.

Thanks for the context/motivation.

Maybe I could say something like:

Tools like wasm-bindgen frequently perform these conversions using TextEncoder and TextDecoder interfaces in order to pass Strings from JavaScript to WASM efficiently. Since these classes are not available in the bidder, seller, or reporting script environments, protectedAudience.encodeUtf8 and decodeUtf8 functions provide a way of efficiently polyfilling the minimum needed subset of their functionality. For example, a version incorporating feature detection:

TextEncoder = function() {}
TextEncoder.prototype = {}
if (globalThis.protectedAudience && protectedAudience.encodeUtf8) {
   TextEncoder.prototype.encode = protectedAudience.encodeUtf8;
} else {
   TextEncoder.prototype.encode = slowerJavaScriptEncodeImplementation;
}

Pushed this, so PTAL if you can (though I dunno if CMA pre-review process stuff is doable in half a day).