fix(http): make handler-error status visible in access log + transcription errors

[localai-bot]

Summary

Two small, focused fixes that together close an observability gap around transcription failures (and any handler that returns err to Echo's central error handler).

• fix(http): log accurate status code when handler returns error — The custom xlog access-log middleware in API() reads res.Status before Echo's central HTTPErrorHandler runs, so when a handler returns an error without writing a response, the status field stays at its default 200. Every 500/503/etc. that flows through Echo's error handler was silently logged as 200. Now mirrors echo.DefaultHTTPErrorHandler's derivation: default to 500, upgrade to *echo.HTTPError.Code if applicable.
• fix(transcription): log underlying error before returning 500 to client — TranscriptEndpoint did return err on backend failure; the actual error (gRPC error from a remote node, model load issue, ffmpeg crash, etc.) was lost. Now logs model name, staged audio path, and the underlying error before returning.

Why these together

Operators chasing transcription failures across distributed mode were getting "upstream returned 500" on the client, status=200 in the access log, and zero context anywhere in the frontend's logs. With both fixes:

• the access-log line tells you the real status code
• the Error line tells you what actually failed
• Fix llama-cli: command not found #1 also benefits every other endpoint that returns errors via Echo's central handler

Test plan

• Trigger a transcription against a model whose worker is unreachable; verify the frontend logs Transcription failed ... error=... and an access-log line with status=500.
• Confirm successful transcriptions still log status=200 (no regression).
• Confirm 4xx returns from middleware (e.g. bad request) log the right status code, not 500.
• Spot-check a non-transcription endpoint that returns an error — its access line should now reflect the correct status too.

🤖 Generated with Claude Code