[EPIC] Operational logging

[ypldan]

Goal

Raise the operational value of the service's logs around two principles:

1. INFO tells the story of a request — arrival, orchestrator iterations, tools called by name with durations and outcomes, completion — enough to investigate most production issues without switching to DEBUG.
2. Logs favor structure over content — roles, counts, sizes, names, ids, statuses rather than message bodies and tool arguments.

Along the way, fix OTLP log export, remove inert logging settings, standardize exception-logging conventions, and add a first-class structured output mode.

Scope — child issues

• Remove inert logging settings and dead code #432
• App logs are not exported when OTEL_LOGS_EXPORTER=otlp #433
• Design: log levels & content policy #434
• Request-lifecycle events at INFO + level rebalance #435
• Prefer structure over payload content in logs #436
• Standardize exception-logging conventions #437
• Structured (JSON) logging mode #438
• Request-scoped log context #439
• Stage content disclosure policy #440

Out of scope

• Metrics and tracing (only the log pipeline and log content are in scope).
• Log-based alerting/dashboards.
• Logging in other DIAL components.

Dependencies and sequencing

• #432 and #433 are independent quick wins — start immediately.
• #434 (design) gates #435 and #436.
• #437 is design-independent and can run in parallel.
• #438 before #439 (field naming contract); #440 last, aligned with the merged error-protocol design (Resolve error causes and deliver failures through the DIAL error protocol #411, delivered in PR feat: resolve error causes and deliver failures through the DIAL error protocol #411 #412).
• Each child PR carries its own tests and doc updates.

Additional information

Related: #284 (OTEL trace correlation, delivered in PR #285), PR #409 (LOG_FORMAT docs), #411 (error protocol, delivered in PR #412).