fix(cloudflare): Reject unknown keys in options callbacks - #23290

A plain `CloudflareOptions` parameter already rejects unknown keys when the
caller writes a direct object literal, which is why it is enough everywhere
else. That check does not survive a function boundary though, and since `env`
only exists at request time, a callback is the only way to configure these
APIs — so typos went unreported:

    withSentry(() => ({ dsn, tracesSampleRte: 1 }), handler) // compiled fine

`StrictCloudflareOptions<O>` rebuilds the check for the callbacks only: it
infers the returned literal into `O` and intersects it with a `never` map over
its unknown keys. A function-rejecting branch keeps "returned the options
factory instead of calling it" an error, which the intersection would otherwise
allow. The object forms stay on plain `CloudflareOptions`.

Note this is top level only — nested option objects stay unchecked — and it
also rejects a pre-built object carrying extra keys, which a plain excess
property check would allow.

Two bugs this surfaced: the Hono Cloudflare middleware spread the
middleware-only `shouldHandleError` into the SDK options, and `serverName` was
missing from `CloudflareOptions` despite being consumed by `ServerRuntimeClient`.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>