docs: distinguish IO forks from CPU parallel calls

[oxura]

Closes #1375.

Clarify the intended current policy rather than changing the IO scheduler:

• IO computations take turns on one event loop; waiting on a socket, sleep or channel lets others run.
• IO.fork starts an IO computation and returns its result channel, not an automatic CPU-parallel job.
• Pure work in different forks does not overlap on CPU cores automatically. Link the existing parallel-let section for splitting that work.
• Keep IO.join, channel primitives, deadline/loser behavior and deadlock documentation intact.

Evidence

The native source matches this policy: IO.fork wraps IO.spawn, the spawn primitive queues an IoWork, and io_loop calls io_step on the event-loop environment. io_step synchronously evaluates the continuation before handling its next effect.

Compiled and ran the reporter's unchanged 4,000,000,000-iteration, clock-seeded workloads on Linux with clang 22.1.8 and --gpu off:

Workload	1 thread, elapsed	16 threads, elapsed	16 threads, user CPU
Four IO.fork jobs	1.793 s	1.797 s	1.791 s
Same four jobs sequentially	1.812 s	1.802 s	1.793 s
Two explicit parallel lets	1.797 s	0.905 s	1.791 s

Every run exited 0. Both forked/sequential workloads produced four job results and the correct U32 sum of those results. These measurements are local evidence, not a permanent timing test or a performance guarantee.

• Actual bun bend2/main.ts guide exposes the new distinction.
• bun gates/repo.ts: PASS 50 / 50.

No runtime/backend changes; no wording-only or noisy timing tests added. The unavailable mini-cluster gates were not run.

[nicolas-abril]

Thanks @oxura for tracking this down, and @Lorenzobattistela for the rewrite! I pushed one small commit on top (df25e1a) before merging. The sentence now reads:

A Bend program is a set of computations interleaved by one event loop, as in Node.js: one at a time, each runs its pure code, on every core through its parallel calls, up to its next effect, and one that waits on a socket, a sleep or a channel steps aside for the others.

Why:

• It keeps the old sentence's shape. The original wording puts the emphasis where it belongs, on the pure computation, which is the essential part of a Bend program. Only its ambiguous "(in parallel, on every core)" changes, to say where the cores come from: the computation's own parallel calls.
• "One at a time" up front is the fix for IO.fork computations run their pure work on one core; the guide says "in parallel, on every core" #1375: forks interleave, they don't add cores. It replaces the parenthetical in the middle of the sentence, which interrupted it. It's also a bit more accurate than "two computations never run at the same time": what never overlaps is their pure code, while the sockets and timers they wait on do progress concurrently.
• It links to the Parallelism section, as the first version of this PR did.
• The rest of the paragraph is rewrapped to 80 columns. The guide stays under its 8000-token cap (7995), and gates/repo.ts passes 50/50.

[oxura]

Thanks @nicolas-abril and @Lorenzobattistela for the final wording and merge. The distinction between interleaving pure work and concurrent socket/timer progress is clearer, and I’ll keep the maintainer-authored guide boundary in mind. No further outside guide rewrite from me.

[nicolas-abril]

We'll be happy to take suggestions from you. This was a good improvement in the end, even if I didn't take your wording directly.

[oxura]

Thanks @nicolas-abril — understood. I’m happy to send focused suggestions or concrete correctness findings while leaving the final guide wording to you. Glad this improvement landed.