Make inbound 404 logs attributable without changing response behavior

[WilliamAGH]

Problem

The development and production Java Chat services emitted 2,840 inbound 404 error-dispatch events between July 10 and July 12, but each event recorded only the status code. The logs could not distinguish ordinary browser probes from unknown API paths or identify the request across services.

This was initially observed in aventurevc/back-end#1118. The affected Coolify resources were Java Chat deployments, not inference-gateway services.

Expected vs Actual

Expected: 404 responses retain their status while logs identify the method, canonical path, host, user agent, request ID, and error source at an appropriate severity.

Actual: every 404 was logged as a generic error without request attribution.

Tasks

• Log bounded, single-line request metadata from the error-dispatch owner.
• Keep non-API 404 probes at info level.
• Log unknown /api paths at warning level.
• Keep server errors at error level with the originating exception.
• Add MVC coverage for each severity and metadata contract.

Acceptance Criteria

• Existing HTML and JSON error response behavior and status codes are unchanged.
• Query strings and control characters cannot leak into or forge log lines.
• Representative 404s can be correlated by servlet request ID.
• Targeted MVC tests and Java formatting checks pass.

Related to aventurevc/back-end#1118.