…ator` to `server.respond`, so `event.platform` and platform emulation are lost during `npm run preview`.

This commit fixes the issue reported at packages/kit/src/exports/vite/preview/index.js:240

## Bug

In the refactor of `packages/kit/src/exports/vite/preview/index.js`, two things were removed:

```js
// removed before `return () => {`
const emulator = await svelte_config.kit.adapter?.emulate?.();
```
and the `emulator` property passed to `server.respond(...)` in the SSR middleware.

### Why it's a regression

The PR's stated purpose is only to let adapters provide Vite plugins for the preview server (`adapter_preview`). But in the **common case** where an adapter does *not* provide a preview plugin (`adapter_preview` is `false`), the built-in preview server still runs and handles SSR requests via `server.respond(...)`. With the emulator no longer computed or passed, `event.platform` is never populated during `npm run preview`.

### Concrete trigger

Run `npm run preview` with any adapter that implements `emulate()` (e.g. `adapter-cloudflare`, `adapter-node`, `adapter-vercel`, `adapter-netlify`) and that does *not* register a `configurePreviewServer` Vite plugin. Any `load`/`action`/handler that reads `event.platform` (e.g. `platform.env` bindings on Cloudflare) will now receive `undefined` instead of the emulated platform, whereas it worked in the parent commit.

### Consistency check

The sibling dev server (`packages/kit/src/exports/vite/dev/index.js`) still computes `const emulator = await svelte_config.kit.adapter?.emulate?.();` and passes it to `server.respond`, confirming the preview removal was accidental.

## Fix

Restored the emulator handling in preview:

- Added `Emulator` to the `@sveltejs/kit` `@import` at the top of the file.
- Declared `let emulator` (typed `Emulator | undefined`) alongside `server`/`manifest`.
- Assigned `emulator = await svelte_config.kit.adapter?.emulate?.();` inside the `if (!adapter_preview)` block, since it is only needed when the built-in server handles requests.
- Passed `emulator` back into the `server.respond(...)` options object in the SSR middleware.

This restores platform emulation during `npm run preview` while keeping the new plugin-based preview path (`adapter_preview === true`) unaffected.

Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: teemingc <[email protected]>

…Error` when an adapter sets `vite` without `plugins`

This commit fixes the issue reported at packages/kit/src/exports/vite/dev/index.js:431

## Bug

In `packages/kit/src/exports/vite/dev/index.js` and `packages/kit/src/exports/vite/preview/index.js`, the code calls `.some(...)` directly on `plugins`:

```js
const adapter_dev = svelte_config.kit.adapter?.vite?.plugins.some(
	(plugin) => plugin.configureServer
);
```

The adapter `vite` option type in `packages/kit/src/exports/public.d.ts` is:

```ts
vite?: {
	...
	plugins?: Plugin[];
};
```

Both `vite` and `plugins` are optional. The optional chaining `?.vite?.plugins` short-circuits only when `adapter` or `vite` is nullish. If an adapter sets `vite` **without** `plugins` (e.g. `vite: {}`), then `plugins` is `undefined` and `.some(...)` is invoked on `undefined`, throwing:

```
TypeError: Cannot read properties of undefined (reading 'some')
```

This crashes dev server startup (`dev/index.js`) and preview startup (`preview/index.js`).

## Fix

Added the missing optional chaining so the call short-circuits when `plugins` is absent:

```js
svelte_config.kit.adapter?.vite?.plugins?.some(...)
```

This matches the safe access pattern already used elsewhere (e.g. `vite/index.js` uses `?.vite?.plugins` with `.filter(Boolean)`).


Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: teemingc <[email protected]>