fix(runtime): adopt returned promise state on async tail-return (#4828)

[proggeramlug]

Fixes #4828.

Problem

An async function whose tail expression returns an un-awaited promise (return someAsyncCall()) corrupted the resolved value. Awaiting the outer fn produced the inner Promise object itself — typeof === "object", JSON.stringify === "", every property undefined — instead of the inner promise's eventual value. Adding an explicit await (const r = await someAsyncCall(); return r;) worked. This is a very common JS pattern, so impact is broad (a createCustomer flow returned "" to its caller, breaking redirects).

Root cause

js_async_step_done (crates/perry-runtime/src/promise/async_step.rs) settles the async fn's result promise two ways. The slow path uses js_promise_resolved(value), which performs ECMAScript thenable/promise adoption (native-Promise short-circuit #2823, thenable assimilation #586). The in-place reuse fast path — taken in steady state when the microtask runner has stashed the result promise in INLINE_TRAP.trap_next — bypassed adoption with the low-level js_promise_resolve(trap_next, value), storing the returned Promise object as the literal resolution value. The sibling js_async_step_chain (the await x path) already adopts, which is why explicit await masked the bug.

Fix

Added resolve_trap_next_with_adoption, mirroring js_promise_resolved's adoption probes (primitive short-circuit, native-Promise chain via js_promise_resolve_with_promise, thenable assimilation) but settling the existing trap_next rather than allocating a fresh promise — so the runner's self-chain fast path still fires. The fast path now calls it instead of the raw js_promise_resolve.

Verification

Compiled and ran the issue's repro (test-files/test_issue_4828_async_tail_promise.ts). Before: broken: ... json="" .id=undefined. After, both lines identical and correct:

broken: typeof=object json={"id":"abc","n":1} .id="abc"
fixed:  typeof=object json={"id":"abc","n":1} .id="abc"