fix: validate project chat request bodies before side effects

From the PR description

Summary

Validate project-chat request payloads at runtime before database, document-context, or LLM work. The shared parsers also keep /chat and project chat from drifting apart.

Closes #278. Supersedes the stale implementation in #155.

Why / Motivation

POST /projects/:projectId/chat previously trusted a TypeScript assertion. Malformed values could create a chat and reach downstream document and model work before failing.

Changes

• Add shared parsers for messages, chat and project IDs, model, displayed and attached documents, and ask_inputs_response.
• Restrict message roles to user and assistant, normalize accepted strings, and return field-specific 400 details.
• Validate both chat routes before side effects while preserving canonical filename lookup and spotlighting.
• Add parser tests and route integration tests that assert malformed project-chat requests do not reach database, document-context, or LLM seams.

Tradeoffs & risks

• /chat now applies the same strict role and nested-payload validation as project chat; malformed payloads that were previously tolerated return 400.
• Open PRs #156, #170, #221, #260, #267, #268, and #271 touch one or both route files for separate downstream behavior, so this branch may need a rebase if one lands first.
• This is request-shape validation only; it does not change authorization or model selection.

How verified

• npm test --prefix backend -- --run src/lib/chat/__tests__/requestValidation.test.ts src/__tests__/integration/chat.routes.test.ts src/__tests__/integration/projectChat.routes.test.ts - 46 passed.
• npm test --prefix backend - 462 passed, 14 skipped.
• npm run build --prefix backend
• A baseline regression test confirmed malformed messages crossed database, document-context, and LLM seams on current main; the candidate route tests verify rejection before those seams.

Checklist

• Ran the relevant build/test command for the area changed.
• Reviewed git diff and removed unrelated changes.
• No documentation or environment example updates are needed for this request-validation fix.
• No secrets, API keys, real documents, or .env files committed.