webpack compile fails at middleware.ts with keystone in next@13 [edge readiness]

This is might be part of general edge readiness effort; unsure if it belongs in bugs or feature requests. Feel free to have a read and move over 🤷

## Repro steps
1. `next@13.3.1` and `@keystone-6/core@5.2.0`
2. Have `src/middleware.ts` which imports any keystone assets (i.e. the schema, or keystone config)
3. Try to retrieve keystone context i.e. for access control.

## Expected

1. Compilation succeeds.

## Actual

In `next@13` middleware is always run in the `edge` runtime, hence can't use any node modules or features. Keystone seems to non-optionally require `@aws-sdk` which is not edge-friendly, which breaks things.

There's a discussion around this type of failure here: https://github.com/vercel/next.js/issues/28774#issuecomment-1526897155

There are other threads around being able to opt-out of edge for middleware, however I don't see that happening any time soon in Next.

```
dev:next: wait - compiling /src/middleware (client and server)...
dev:next: error - node:fs
dev:next: Module build failed: UnhandledSchemeError: Reading from "node:fs" is not handled by plugins (Unhandled scheme).
dev:next: Webpack supports "data:" and "file:" URIs by default.
dev:next: You may need an additional plugin to handle "node:" URIs.
dev:next: Import trace for requested module:
dev:next: node:fs
dev:next: ./node_modules/.pnpm/strtok3@7.0.0/node_modules/strtok3/lib/FsPromise.js
dev:next: ./node_modules/.pnpm/strtok3@7.0.0/node_modules/strtok3/lib/index.js
dev:next: ./node_modules/.pnpm/file-type@18.3.0/node_modules/file-type/index.js
dev:next: ./node_modules/.pnpm/@keystone-6+core@5.2.0_@aws-sdk+abort-controller@3.310.0_@babel+core@7.21.4_@opentelemetry+ap_eexecvfunafgo67t2ljvtiogxm/node_modules/@keystone-6/core/dist/createSystem-a93ebf95.esm.js
dev:next: ./node_modules/.pnpm/@keystone-6+core@5.2.0_@aws-sdk+abort-controller@3.310.0_@babel+core@7.21.4_@opentelemetry+ap_eexecvfunafgo67t2ljvtiogxm/node_modules/@keystone-6/core/context/dist/keystone-6-core-context.esm.js
dev:next: ./src/keystone/context.ts
dev:next: ./src/server/auth.ts
```

## Workaround ?

The only way is to avoid any cross imports between `middleware.ts` and Keystone, which makes it impossible to use keystone queries for access control, which is a major issue for me 😞

Reproduce the failure with next@13.3.1, @keystone-6/core@5.2.0, and an import from src/middleware.ts, then trace the reported node:fs path through src/keystone/context.ts and src/server/auth.ts. Done means middleware compilation succeeds while retaining the requested Keystone context access for access control.

Written by the indexing model from the issue text.