test(xpp): verify .await() inside spawned fns + correct spawn.h docs

[mivinci]

Summary

Empirically settles the "can you .await() inside xpp::spawn?" question with tests, and corrects the spawn.h docs that said it "would block unless already inside a fiber" — which was misleading.

Verified semantics (4 new tests)

Test	Verifies
AwaitInsideSpawnedFn	A spawned fn .await()s a channel recv; a timer feeds the channel while the fn is parked — park() re-enters the event loop, the world keeps turning
SequentialAwaitsInsideSpawnedFn	Two park/resume cycles in one fn (each .await() parks, gets fed by its own timer, resumes)
AwaitTimerInsideSpawnedFn	.await() on a timer promise directly
AwaitCrossChainInsideSpawnedFn	Chain A awaits a promise that chain B resolves after a timer — cross-chain .await(), both chains spawned on the same loop

Doc correction (spawn.h)

The old text discouraged .await() inside spawned fns. The corrected doc states:

• Usable: parks the fn's stack while re-entering the event loop (park() runs X_RUN_ONCE until woken) — timers, I/O, other chains keep progressing
• Idiomatic forms remain .then() chains (C++11) / co_await (C++20) — waker-driven, no parked stack — but plain sequential .await() works when convenient
• Deadlock boundary documented: awaiting anything that only resolves after the fn returns (e.g. the spawn's own JoinHandle) is a circular wait and hangs — not tested here since it would hang CI

Context: this came out of evaluating a WaitScope-fiber design (make .await() a true suspension via a loop fiber). The design was explored and rejected — the re-entrant park model already delivers the observable semantics; the fiber design's costs (livelock traps, lifecycle dance) outweighed its aesthetic benefit. The tests + doc correction are the durable output of that exploration.

Verification

• spawn_test 14/14 (ASan, 4 new)
• TSan: 0 warnings
• Related promise suites green