server-compat: Bun.serve (optional)

[shinagawa-web]

Part of #37 (v0.2.0 server-compatibility exercise).

Goal

Manually exercise tinytap against Bun.serve and record what we can and can't observe, feeding the shared table in docs/server-compat.md. This server is optional / niche — do it after the four main servers (Python, Go, Node, nginx) are done.

This is manual exploration, not automated tests.

Setup

A minimal Bun.serve({ fetch }) with two responses: an inline new Response("Hello, world") and a file response via new Response(Bun.file(path)).

Bun's runtime is Zig-based; Bun.file() responses may take a sendfile(2) fast path. Confirm whether the file body is visible and how it differs from the inline string response.

Tasks

• Serve a "Hello, world" endpoint + a Bun.file file-serving endpoint
• Run tinytap + curl against three body sizes: small (<256 B), medium (~1 KiB), large (~50 KiB)
• Capture for each:
  • per-syscall write sizes (raw event log)
  • whether the body is visible in TUI / how it's truncated
  • whether sendfile(2) is used (absence of write/sendto events on body bytes)
• Add a Bun row block to docs/server-compat.md
• Note any surprises (TCP_CORK, MSG_MORE, kernel buffering) for Lift the 256-byte BPF payload sample cap #36

Done when

• docs/server-compat.md has Bun.serve × 3 body sizes filled in
• The doc records whether Bun.file() uses sendfile vs the visible inline-string path