Track backend-neutral async and await support

## Summary

Track backend-neutral `async`/`await` support for Wave from syntax through runtime integration.

The initial language direction is:

```wave
async fun load() -> i64 {
var value: i64 = await read_value();
return value;
}
```

- `async fun name(...) -> T` produces an asynchronous computation whose completed value is `T`.
- `await expression` suspends only the current asynchronous computation.
- `var` remains Wave's local-variable syntax; async support must not introduce `let`, borrow checking, or Rust-style `unsafe` blocks.
- `fun main()` remains the private entry point. `pub async fun main()` is invalid, and support for private `async fun main()` requires an explicit executor entry contract.
- Direct `extern` and exported async functions are initially rejected because no stable C or Wave ABI exists for async frames.
- The frontend contract must be backend-neutral so LLVM can later be replaced by Whale without changing language semantics.

## Child issues

- [ ] #440
- [ ] #441
- [ ] #442
- [ ] #443
- [ ] #444
- [ ] #445

## Non-goals

- HTTP, TLS, or protocol libraries in `std`.
- An LLVM-specific coroutine ABI as part of the Wave language.
- Implicit memory safety or ownership rules that Wave does not otherwise provide.
- Stable async FFI before the Wave ABI is designed.

This tracking issue should be completed through focused child issues rather than one monolithic pull request.

Start by reading child issues #440 through #445, since this tracker explicitly delegates the work rather than naming an implementation entry point. Use those focused issues to determine the relevant syntax, frontend, runtime, and executor work; this issue is done when the child issues are completed without violating the listed non-goals.

Written by the indexing model from the issue text.