This PR adds a failing test that covers a bug found in vitejs/vite#21626.

When lazy bundling is enabled, the following bug exists:

```javascript
try {
  await import('./foo.js'); // throws an error inside
} catch (e) {
  // the error is not caught here and a unhandled error happens
}
```

<!--
- What is this PR solving? Write a clear and concise description.
- Reference the issues it solves (e.g. `fixes #123`).
- What other alternatives have you explored?
- Are there any parts you think require more attention from reviewers?

Also, please make sure you do the following:

- Read the Contributing Guidelines at https://rolldown.rs/contribution-guide/.
- Check that there isn't already a PR that solves the problem the same way. If you find a duplicate, please help us review it.
- Update the corresponding documentation if needed.
- Include relevant tests that fail without this PR but pass with it. If the tests are not included, explain why.

Thank you for contributing to Rolldown!
-->

Builds on #9975 (which added the failing test). Fixes the bug found in vitejs/vite#21626.

## Problem

With lazy compilation enabled, an error thrown while a lazily-imported module *initializes* never reached the consumer:

```js
try {
  await import('./foo.js'); // throws during init
} catch (e) {
  // never runs — instead the error escaped as an unhandled rejection,
  // and `await import(...)` resolved as if nothing went wrong
}
```

The lazy proxy wraps the import in an eagerly-created `lazyExports` async IIFE. On the first compile of the lazy chunk (the on-demand `@vite/lazy` response), the real module's initializer runs synchronously inside that IIFE and throws, so `lazyExports` rejects before any consumer can attach a handler. The rejection went unhandled, and the proxy then returned the module namespace as if the import had succeeded.

## Fix

- **`proxy-module-template.js`**: after loading the chunk, `await` the real module's own `rolldown:exports` promise instead of just handing back the namespace from `loadExports`. An error during init now rejects `lazyExports` too, so it surfaces at the consumer's `await import(...)` (catchable) rather than escaping as an unhandled rejection.

## Tests

- Rewrote the `lazy-init-error` spec to assert both cases against the same module: with `try/catch` the error is caught at `await import(...)`; with no handler it surfaces as exactly one `unhandledrejection`.