Improve client-to-server logging endpoint #1635

Description

The /logger route has several issues with its API design:

1. Payload in headers — level and message are sent as HTTP headers rather than in the request body. Headers are meant for metadata, not payload, and this limits message size.

2. Wrong status codes — Missing level, missing message, and unrecognized log level all return 500 via the error middleware. These are client errors and should be 400 Bad Request.

3. Fragile message parsing — The message is JSON-stringified on the client, JSON-parsed on the server, then backslashes are stripped with replaceAll("\\", ""). Legitimate backslashes (file paths, regex patterns) get eaten. This workaround should be unnecessary with a proper JSON body.

4. Manual level dispatch — The if/else chain for log levels is unnecessary. Pino supports logger[level](message) for all valid levels.

5. No source tagging — Client-originated log entries are indistinguishable from server-originated ones when reading logs.

6. Route name — /logger is a noun describing the tool, not the action. /log is more conventional for a logging endpoint.

Preferred Solution

Server (/log route)

• Rename the route from /logger to /log
• Accept a JSON body: { level: string, message: string }
• Validate level against the allowlist (error, warn, info, debug, trace) and return 400 for invalid values
• Return 400 for missing level or message
• Use Pino's method dispatch: logger[level]({ source: "client" }, message) instead of the if/else chain
• Tag all client log entries with source: "client" so they are distinguishable in server logs
• Keep /logger as a deprecated alias during a transition period

Client (ServerLoggerConnector)

• Send level and message in the JSON request body instead of headers
• Update the endpoint URL from /logger to /log

Request logging middleware

• Update the path filter to skip /log instead of /logger