More deduplication and cleanup in TS streams

[jasnell]

A TransformStreamDefaultController was created and then attached to
its stream in one synchronous step, before any user code could reach
it, so the four "Controller is not attached to a stream" throws in
its methods could never fire. The controller now takes its stream as
a constructor argument, as ReadableStreamDefaultController does, and
the init slot goes. Its length stays 0, which the module sets
explicitly.

The inner streams' start algorithms record their controllers while
the TransformStream constructor builds the pair, before
transformer.start(), the first user code that can reach it. The two
fields are now typed as always set, and the nine checks for an unset
one go, among them desiredSize's null arm and enqueue's
"TransformStream is not fully initialized" throw.

Nothing observable changes.

[clanky-the-clanker]

✅ Approved — This is a behaviour-preserving cleanup with no findings. The inner streams' controllers are recorded synchronously during construction, which makes the removed unset-checks unreachable, as the description says.

_{The decision is advisory: this comment never approves, blocks or requests changes on the pull request.}

---

✅ All checks passed

🔒 Security: ✅ LGTM

No security concerns.

---

📖 AGENTS.md: ✅ LGTM

No AGENTS.md updates are needed.

---

📋 Code Quality: ✅ LGTM

No correctness problems were found in transform.ts or readable.ts.

• Controllers always set: The writable's and readable's start callbacks (transform.ts:548-551, transform.ts:568-571) assign #writableController and #readableController. The inner controllers call start synchronously from their constructors (for example writable.ts:1180-1183). Both fields are therefore set before transformer.start() runs, so typing them as always set and removing the unset checks is sound.
• Merged finish path: #finish keeps the earlier behaviour for each of its three cases:
  • close runs the flush algorithm; on success it closes the readable.
  • abort runs the cancel algorithm; on success it errors the readable with the reason.
  • cancel runs the cancel algorithm; on success it errors the writable.
  • In every case the finish promise is set before the algorithm runs, and a rejection errors the half that ended.
• #closeReadable: It now checks canCloseOrEnqueue before closing, in place of the old try/catch. The result is the same.
• Controller constructor: TransformStreamDefaultController now takes its stream as a constructor argument. This removes the init slot and the four "not attached" throws, which could never fire.

---

⚡ Performance: ✅ LGTM

No performance concerns.

---

📝 Documentation: ✅ LGTM

The updated comments describe the current code.

---

_{Reviewed commit: 7f02098d}

[ask-bonk]

Since last review: 0 resolved, 0 still open, 1 new.
LGTM!

The TransformStream cleanup remains sound; the completion-path comment still needs correction.

Other findings

• [INFO] src/per_isolate/webstreams/transform.ts:330: terminate() closes the readable side but errors the writable side. Therefore a pending close or abort observes a closed readable and resolves after its algorithm fulfills; only cancel observes the writable error and rejects. Update the comment so it does not promise rejection for all three paths.

  // it, as does any started later. The ended half's state is read when the
  // algorithm settles (step 7.1.1). A prior abort or error that reached it
  // rejects the finish with its stored error; terminate() does so for cancel
  // because it errors the writable, while close and abort observe the readable,
  // which terminate() closes.
  

Carried forward from the last review: docs (no author changes in their files since then; earlier findings stand)

Not re-run: api-compat, tests, compat-flags, design-simplicity (no author changes in their files since the last review)

---

_{Reviewed commit: 7f02098d · github run}