fix(chat): drop the documentContext alias no shipped client ever used

WHY THIS MATTERS
POST /chat accepted the document body under two spellings:

  body.document_context ?? body.documentContext

with a comment claiming the camelCase alias protected "add-in builds
that shipped before the field was aligned". But no such builds exist:
word-addin/ is introduced by this very PR, and its vendored client has
sent snake_case `document_context` from the start. The alias guarded
against a past that never happened - and compatibility shims are not
free. Every alias doubles the surface a validator, a security fence,
and future maintainers must reason about, and once an alias ships,
external callers CAN start depending on it, turning a fictional
obligation into a real one.

WHAT IS API SURFACE MINIMALISM
An HTTP body field is a public contract. The rule of thumb: accept
exactly one spelling per field, and only add an alias when a concrete,
identifiable client population depends on the old one. "Someone might
have..." is not such a population - version control history is. If a
legacy spelling genuinely exists in the wild you keep it with a dated
deprecation note; if it provably doesn't, the kindest thing for the
contract is to never let it exist.

HOW THE FIX WORKS
The route now parses only the documented snake_case field:

  const parsedDocumentContext = parseOptionalDocumentContext(
      body.document_context,
  );

and the integration test that pinned the alias ("accepts the deprecated
documentContext alias") is deleted with it - a test whose only job was
to keep dead surface alive. The snake_case tests (400 on non-string,
nonce-fenced injection into the system prompt) still cover the field's
real contract.

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