Should the Dynamic Worker Loader API validate the WorkerCode object passed to it?

You can add any arbitrary key onto the [`WorkerCode` object](https://developers.cloudflare.com/workers/runtime-apis/bindings/worker-loader/#workercode) that gets passed into the Dynamic Worker loader API, and the runtime will ignore nonsense / unused keys on the object, ex `blarg`:

```ts
const worker = env.LOADER.get('some-id-you-define', () => {
return {
compatibilityDate: "2025-06-01",
mainModule: "index.js",
modules: {
"index.js": untrustedCode
},
blarg: "blarg",
env: {
// Provide the untrusted code with a custom API
CUSTOM_BINDING_API: ctx.exports.Greeter({ props : { greeting: 'Hello' }}),
// Provide the untrusted code with any environment variables
USERNAME: 'brendan'
}
};
});
```

...and things will still work and run.

But this means that working with an LLM who doesn't know the dynamic Worker loader API, it will make things up — ex: I was working with Claude Code and it just invented there being a `bindings` key on this object, and tried passing in bindings in the same shape as bindings from `wrangler.jsonc`

The net impact of this was that I saw an error in the dynamic Worker because of a missing object on `env` — which was a less direct place for the error to occur. I'd have wanted this to fail earlier, loudly, and be clear — what you passed into the Worker loader isn't valid

I wonder if we should be validating input arguments, and throwing a loud error if you add things onto this object that aren't valid? Maybe this is too restrictive but hitting this made me think about implications of LLMs intersecting with new APIs. This was even _with_ me feeding Claude the Worker Loader API docs, which really surprised me.

@dinasaur404 @kentonv for thoughts

Start with the Dynamic Worker Loader API entry point and the linked WorkerCode documentation to compare documented fields with the runtime's accepted input. Determine the intended behavior for unknown keys such as `blarg` and malformed binding shapes, then define the validation and error expectations. Done means the behavior is decided and covered for invalid WorkerCode input.

Written by the indexing model from the issue text.