String chunks are hashed as WTF-8, which encodes a lone surrogate
literally (U+D800 becomes ED A0 80) rather than substituting U+FFFD as
TextEncoder and every other UTF-8 producer would. That stays the default,
since changing it would silently alter the digests of existing callers,
but `new DigestStream(algorithm, {toWellFormed: true})` now opts into the
substitution.

Under toWellFormed the conversion is a streaming text encoder, so a
surrogate pair split across two writes is joined rather than being
mistaken for two unpaired surrogates: a lead surrogate ending a chunk is
held back until the next chunk settles whether it pairs, and flushed as
U+FFFD at end of stream if it never does. This mirrors TextEncoderStream.
The default encoding stays stateless and joins nothing, which is why the
two can disagree on bytesWritten across chunks -- 4 bytes for a joined
pair against 3+3 for two lone surrogates.

Both DigestStream implementations share DigestStringEncoder, so they
cannot drift apart under either encoding. The shared test file pins the
default (stringChunksAreNotTextEncodedByDefault) and the opt-in
(toWellFormedMatchesTextEncoder) against both, along with JSG's option
bag rules, which the TypeScript side has to reproduce by hand.

The CRC names were compared exactly while every other name went to
EVP_get_digestbyname, which is case-insensitive. So md5 and MD5 both
worked but CRC32 did not, an inconsistency with nothing behind it.

No compatibility flag is needed because the change only widens what is
accepted: every name that worked before still selects the same algorithm,
and the newly accepted spellings previously threw. The pre-existing casing
test confirmed CRC32 threw, which rules out an OpenSSL digest already
answering to that name and now being shadowed by a CRC.

Both implementations reach newDigestContext, so this fixes them together.
The tests compare digests rather than just checking that the constructor
did not throw, since a casing that silently selected a different algorithm
would otherwise pass.