v0.5.48

• A web Response keeps the Set-Cookie and Set-Cookie2 headers it is
  built with, as Node's (undici's) does: getSetCookie() lists each, get
  joins them with ", ", iteration yields one entry per cookie, and a later
  append or set keeps them too. The guest's Response was the browser's,
  whose response guard drops both silently, so a server that answers with a web
  Response lost every cookie it set before its answer reached the socket; in a
  tab, Dub's /api/auth/csrf (NextAuth under next start) answered with none.
  The realm's Response is still the browser's class but for its constructor,
  which shares the browser's prototype: a fetch's answer, Response.error() and
  a subclass are instanceof Response with Response as their constructor.
  Response.json and clone() keep the cookies; formData() and blob() read
  a content type changed after construction, as Node's do. A response a host
  transport builds in the realm keeps the cookies of what it relays too. An init
  is read as the platform reads it, inherited status included, so
  new Response(body, otherResponse) (Next's NextResponse.json) keeps its status.