Do not store the suspension sentinel when an await suspends a right-hand side

[HermanusMuellerEU]

Summary

x = await p wrote the suspension sentinel into x on the suspend pass; a
rejecting p left x clobbered to undefined forever.

Details

x = await p evaluates its right-hand side, suspends the async function at
the await, and returns a sentinel value standing in for "no value yet". The
assignment lanes guarded that store with IsGeneratorAborted() only, so on
the suspend pass the sentinel was written straight into the target.

When p RESOLVES the resumed re-entry re-evaluates and stores the real value,
which hid the damage. When p REJECTS the resumption throws before it reaches
the store, and the target is left clobbered for good:

​js let value = 'initial'; try { value = await Promise.reject(new Error('boom')); } catch (e) { value; // undefined under Jint; 'initial' per spec and other engines } ​

Same for member targets (obj.prop = await p) and global bindings.
Reproduces on 4.12.0 and current main. We hit it in a real workload as
state that "reset itself" after a failed fetch: every cache = await refresh() in a try/catch wiped the previous cache on failure.

The fix

Per the assignment-operator evaluation semantics
(https://tc39.es/ecma262/#sec-assignment-operators-runtime-semantics-evaluation)
PutValue runs only after GetValue(rref) has actually produced a value — an
await that suspends never reaches the store. Guard the three store sites in
JintAssignmentExpression (SetValue, AssignToIdentifier,
AssignToCachedGlobalBinding) on context.IsSuspended() in addition to
IsGeneratorAborted().

JintMemberExpression.TryAssignFast needs no equivalent guard — it already
declines whenever the execution context is suspendable.

Linked issue

No existing issue covers this; happy to file one if preferred.

Test plan

• Added or updated unit tests in Jint.Tests — four tests in
  Runtime/AsyncTests.cs: rejected-await clobber of a local, of a member
  target, of a global through the warmed cached-global-binding lane (looped so
  the cache is hit), and a resolved-await control that must keep assigning.
  Three fail before the fix; all four pass after.
• Ran dotnet test --configuration Release locally — no new failures
  (identical failure set to unpatched main).
• For ECMAScript spec changes: ran Jint.Tests.Test262 and confirmed no
  regressions (identical results to unpatched main).
• For interop changes: n/a
• For perf changes: n/a — the added check is two flag tests on a path that
  only executes when the context is already suspending.

Breaking change?

No.

[lahma]

Thank you!

[HermanusMuellerEU]

I'll resolve the conflicts as soon as I can.