[P2][Logs] Make invariant and ignore logs actionable

Parent issue: #4691

Intent

Messages such as this should not happen and ignore it state a conclusion without showing the invariant, evidence, or impact. That weakens the diagnostic value of the log even when the event is real. This task rewrites invariant and ignore logs so they are actionable during triage.

Modification points

• For invariant-violation logs, include the violated expectation, the observed value, the impact scope, and the action taken.
• For ignore logs, explain why the event is safe to ignore, what object was dropped, and which current epoch or state made the decision safe.
• Remove templates that only express surprise or dismissal without evidence.

Entry points

• downstreamadapter/dispatcherorchestrator/dispatcher_orchestrator.go:254
• downstreamadapter/eventcollector/dispatcher_stat.go:688
• downstreamadapter/eventcollector/dispatcher_stat.go:521
• downstreamadapter/eventcollector/dispatcher_stat.go:615
• downstreamadapter/eventcollector/dispatcher_stat.go:681

Done criteria

• Readers can tell from the log alone whether the event is an expected drop, a recoverable inconsistency, or a correctness risk.
• this should not happen and ignore it style messages are replaced with evidence-based explanations.
• The remaining logs consistently include expectation, observation, impact, and action.

Start by reading the listed log sites in downstreamadapter/dispatcherorchestrator/dispatcher_orchestrator.go and downstreamadapter/eventcollector/dispatcher_stat.go, especially the specified lines, to understand each event's context. Replace invariant and ignore messages with explanations covering expectation, observation, impact, and action. Done means readers can distinguish expected drops, recoverable inconsistencies, and correctness risks from the logs alone.