[P4][Logs] Replace large zap.Any payloads on hot paths with compact fields

Parent issue: #4691

Intent

Some hot-path logs include large objects, arrays, or raw payloads through zap.Any. Those logs are expensive to encode, expensive to store, and still hard to read because they lack a concise summary. This task replaces large payload dumps on default paths with compact structured fields.

Modification points

• Replace large zap.Any fields on Info and Warn logs with scalar fields and small samples.
• Keep raw events, config blobs, or object dumps only behind Debug or a dedicated diagnostics mode.
• Ensure the retained fields answer the first triage question directly instead of forcing the reader to inspect a large payload.

Entry points

• downstreamadapter/dispatcherorchestrator/dispatcher_orchestrator.go:162
• downstreamadapter/eventcollector/dispatcher_stat.go:521
• downstreamadapter/eventcollector/dispatcher_stat.go:670
• logservice/txnutil/lock_resolver.go:56
• logservice/logpuller/subscription_client.go:1012
• logservice/logpuller/subscription_client.go:1057
• logservice/logpuller/subscription_client.go:1072
• logservice/logpuller/region_request_worker.go:298

Done criteria

• Default logs no longer include large arrays, raw event objects, or config blobs on the targeted hot paths.
• The remaining fields make the incident understandable without inspecting a full dump.
• Full payload detail is still available through lower-level or diagnostics-only logging.

Review the listed call sites in dispatcher_orchestrator.go, dispatcher_stat.go, lock_resolver.go, subscription_client.go, and region_request_worker.go, starting with the specified log statements and their hot-path data. Identify which Info and Warn fields use large zap.Any payloads, then verify that default logs retain concise triage fields while full payloads remain available only through lower-level or diagnostics-only logging.