…name/directory-based server-only detection and allowing server-only code to leak into client bundles

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

## Bug

In `packages/kit/src/exports/vite/index.js` the `plugin_guard` `load`/`handler` computes whether a module is server-only:

```js
let is_server_only = normalized === '$app/env/private' || normalized === '$app/server';

if (id.startsWith(normalized_cwd) && !id.startsWith(normalized_node_modules)) {
    is_server_only ??= server_only_module_pattern.test(id);
    is_server_only ??=
        server_only_directory_pattern.test(id) &&
        !id.startsWith(normalized_routes + '/') &&
        !id.startsWith(normalized_assets + '/');
}

if (!is_server_only) return;
```

`is_server_only` is initialized from `===` comparisons, so it is **always** a boolean (`true`/`false`), never `null`/`undefined`.

`a ??= b` only assigns when `a` is nullish. Since `is_server_only` is `false` for the overwhelmingly common case (the module is not `$app/server` / `$app/env/private`), the RHS of both `??=` statements never executes:

```js
let x = false; x ??= true; // x is still false
```

## Impact

The filename pattern (`*.server.*`) and `server/` directory checks are effectively dead code. Modules that should be flagged server-only via filename/directory conventions are no longer detected, so `find_chain` never fires and the guard that documentation/docs/30-advanced/50-server-only-modules.md promises is disabled. Server-only code (potentially containing secrets) can be silently bundled into the client — a security regression introduced by the refactor in commit caf79f3.

## Fix

Switch both `??=` to `||=` so the checks run whenever `is_server_only` is still falsy, matching the pre-refactor single boolean-OR behavior.


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

…ltejs/kit into consistent-filename-patterns