Release the transformer once a TransformStream finishes

[jasnell]

ClearAlgorithms cleared the cancel and flush algorithms but not the
transform algorithm, and all three closures were built in the
TransformStream constructor, so transformer lived in the constructor's
shared context. Every closure the constructor creates keeps that context
alive, including the interop error hooks the halves hold for good, so the
transformer stayed reachable for as long as the stream did.

The algorithms are now built in a module-level helper, which alone
captures the transformer, and the transform algorithm lives on the
instance beside the other two. ClearAlgorithms drops all three, as the
spec has it, and the transformer is collectable after close, abort,
cancel, terminate() or error(), with the stream still held. Node agrees;
C++ keeps it after close (transform ledger #17).

A write that reaches the sink after readable.cancel() cleared the
algorithms, before the cancel errors the writable, is left undefined by
the spec; like Node, it drops the chunk and fulfills. Behind the
experimental typescript_implemented_streams flag.

[ask-bonk]

LGTM

github run

[guybedford]

The retention fix is right: with the algorithm closures built in makeTransformerAlgorithms, nothing in the constructor's scope references transformer from an inner function (the start() call is direct), so the shared context the interop hooks pin no longer carries it. Verified the gc test collects on all five endings.

One behavioral note on the new dropped-write path (inline), plus two nits:

• The description says "transform ledger #17"; the diff adds row #18.
• Branch is a few commits behind main (rebases cleanly).