Reject unknown fields from native API request bodies

[dongjangoon]

What

Adds #[serde(deny_unknown_fields)] to the lorax-native HTTP request body structs in router/src/lib.rs, so a request containing an unknown or misplaced field fails with a clear deserialization/validation error instead of being silently ignored.

Closes #478.

Why

Per #478, unknown top-level fields are currently dropped silently. A common failure mode is putting api_token at the top level instead of inside parameters, which then surfaces as a confusing "access denied" instead of a validation error. Rejecting unknown fields makes these mistakes obvious at the request boundary.

Structs covered (8 native request bodies)

• GenerateRequest, CompatGenerateRequest, TokenizeRequest
• EmbedRequest, CompatEmbedRequest
• ClassifyRequest, BatchClassifyRequest, BatchEmbedRequest

Deliberately NOT covered

• ChatCompletionRequest / CompletionRequest — these back the OpenAI-compatible /v1/chat/completions and /v1/completions endpoints, which conventionally tolerate unknown fields for forward-compat with the OpenAI spec. These structs already follow that convention (several #[allow(dead_code)] accept-but-ignore fields), and locking them down would reject standard OpenAI params lorax hasn't implemented yet (e.g. stream_options, parallel_tool_calls, max_completion_tokens, top_logprobs) and break real OpenAI SDK clients. Happy to include them if you'd prefer strictness there too.
• JsonSchemaTool — uses #[serde(flatten)], which serde does not allow together with deny_unknown_fields (it's the only flatten in the file, and it isn't a request body).

Notes

• Scope is the top-level request bodies, which covers the motivating case in Reject unknown fields from API requests #478. Nested parameter structs (e.g. GenerateParameters) could be a follow-up.
• I don't have a local Rust toolchain to run cargo build/test; the change is a pure serde container-attribute addition with the one flatten struct excluded, so I'm relying on CI to confirm.