Fix structured concurrency post: clarify await vs caller lifetime

[taras]

Motivation

The original wording conflated two distinct failure modes into one sentence tied to await:

"The moment you await, the work you started no longer has to finish inside the scope that started it — your caller can move on while your effects keep running."

When you await, the caller actually blocks — it doesn't move on. The real "damned if you do, damned if you don't" is:

1. Await (and block) — no guarantee control returns (hard exit, signal, etc.)
2. Don't await (fire and forget) — caller moves on, effects outlive it

The original sentence attributed both damnations to await. This PR separates them.

Approach

One paragraph rewrite in www/blog/2026-02-06-structured-concurrency-for-javascript/index.md:

"Async changes that. Once you cross an await boundary, the caller has two bad options: await (and block) or move on while the work keeps running past its lifetime boundary. Either way, there's nothing built in that can halt it and force cleanup to run."

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/thefrontside/effection@1104

commit: a56921d