feat(node): expose the raw response bytes alongside the decoded text

[onamfc]

The fetcher read every response through a TextDecoder and returned only the string. That is lossy for anything that is not UTF-8, so an image fetched through it could never be recovered — a PNG's leading 0x89 decodes to U+FFFD and the original is gone.

Why it matters now

LinkForty's generated social cards (SIT-368/369) composite a user-supplied logo or hero image into the card, which means fetching an arbitrary URL server-side — exactly the SSRF position this fetcher exists to make safe.

Without access to bytes, that caller had two options: decode-and-hope (broken), or stand up its own fetcher and reimplement the per-hop address checks. The second is worse than it sounds — it would mean two copies of the control that matters most, and the copy would inevitably drift from this one.

The change

readCapped now collects Uint8Array chunks and decodes once at the end:

function toBody(bytes: Uint8Array): { body: string; bodyBytes: Uint8Array } {
  return { body: new TextDecoder().decode(bytes), bodyBytes: bytes };
}

One read, one code path, both shapes. body is byte-for-byte unchanged for existing callers — og-core's parser neither knows nor cares.

bodyBytes is optional on FetchResult so a custom adapter that only ever handles text remains valid.

Verification

• 72 tests, up from 69. Three new cases: raw PNG bytes survive intact and are provably unrecoverable from body; text bodies still decode correctly including multibyte characters; the byte cap applies to both.
• pnpm build, pnpm typecheck, pnpm lint clean.

The PNG test asserts the point directly:

expect(Array.from(result.bodyBytes)).toEqual(Array.from(png));
// The decoded string has already lost the data, which is the whole point.
expect(new TextEncoder().encode(result.body).length).not.toBe(png.length);

Versions

@linkforty/og-core and @linkforty/og-node both to 0.2.0 — minor, since FetchResult gains an optional field and no existing behaviour changes.

Note

This is a design flaw I introduced when specifying SIT-369: I wrote the ticket saying to fetch card images with createNodeFetcher, without checking that it returns text. Fixing it here rather than duplicating the fetcher in Cloud is the correct resolution — the guarded fetcher should be usable for every server-side fetch we do, not just HTML.