amal66 makes Mike's audit trail less likely to spill client data

Chapter: 05 - Observability.

Plain-English map:
Add Pino JSON logging and attach a request ID to each request so related log
lines can be traced together in production.

Why it matters:
Plain text logs are hard to search once many users are active. Structured logs
let operators answer practical questions like "what happened during this one
failed upload?"

Principle:
Production logs should be queryable, consistent, and tied to request context.

Precedent borrowed:
Upstream PR #156 and common production logging practice in hosted services.

Upstream base: willchen96/mike@d39f580.
Original local commit: 6f59af5.

Chapter: 06 - Privacy-aware logging.

Plain-English map:
Replace ad hoc console logging with structured logger calls and remove log
lines that exposed user/document activity identifiers.

Why it matters:
Legal-document activity is sensitive. Logs often flow to third-party systems,
so they should contain only what is useful for debugging and operations.

Principle:
Minimize sensitive data. Treat logs as production data, not scratch paper.

Precedent borrowed:
Upstream PR #80 and GDPR-style data-minimization practice.

Upstream base: willchen96/mike@d39f580.
Original local commit: 9398be6.

Chapter: 26 - Sensitive-path observability.

Plain-English map:
Replace remaining console logging in `chatTools.ts` with the same structured
Pino logger used elsewhere.

Why it matters:
`chatTools.ts` assembles prompts and handles model tool calls. It should have
the same traceability and privacy discipline as the rest of the API.

Principle:
Observability conventions should be consistent, especially in sensitive code.

Precedent borrowed:
Upstream PR #156 and the structured logging baseline from Chapter 05.

Upstream base: willchen96/mike@d39f580.
Original local commit: 921ef5b.