Most likely the value of [Console]::InputEncoding which is the console codepage value of your host.

Confirmed: the stdin bytes are decoded with [Console]::InputEncoding — the console code page of the receiving host (as Jordan Borean (@jborean93) said). It is not UTF-8 unless your console happens to be configured that way.

Verified empirically on Windows PowerShell 5.1 where [Console]::InputEncoding is IBM437: piping the UTF-8 bytes of [int][char]'é' into powershell -NoProfile -Command - fails with Cannot convert value ... "String must be exactly one character long" — the 2-byte UTF-8 sequence for é was decoded as two separate IBM437 characters. Had stdin been UTF-8, it would have printed 233.

Practical takeaways:

• The sender's encoding and the receiver's [Console]::InputEncoding must match. Piping UTF-8 text from a tool into pwsh -Command - on a machine with a legacy OEM input code page mangles non-ASCII (mojibake or parse errors like above).
• You cannot fix this from inside the piped script for the already-open stdin stream — inspect [Console]::InputEncoding on the target machine and make the sender match it.
• Reliable alternatives for non-ASCII code: -EncodedCommand (documented UTF-16LE Base64) or -File with a BOM/saved encoding.
• Do not mix up the three knobs: $OutputEncoding = what PowerShell sends to native processes; [Console]::OutputEncoding = how it decodes native stdout for display; [Console]::InputEncoding = this one, how stdin bytes are decoded. See about_Character_Encoding and about_Pwsh.