Runtime owner-DM correlation hooks investigation

過去レポートのView/ソース規律バックフィルで生成したView。

Summary

The runtime already has a session-scoped Telegram inbound-turn delivery marker, but it is not enough for exact per-message delivery correlation.

Evidence inspected:

• dist/bot-Ce301bOE.js builds Telegram inbound context with MessageSid: String(msg.message_id) and calls beginTelegramInboundTurnDeliveryCorrelation(ctxPayload.SessionKey, ...) around reply dispatch.
• dist/inbound-turn-delivery-CW53u6NG.js stores one active turn per sessionKey and marks delivered when outbound delivery succeeds for the same session/account/chat.
• dist/delivery-CZV2kWBm.js logs outbound successes as telegram sendMessage ok chat=<chatId> message=<outboundMessageId> but does not include the inbound MessageSid / update id in the log line or sent hook context.

Why full per-message proof is still blocked

Current runtime correlation is session-scoped/time-scoped, not log-visible per inbound message. The reliability checker can infer likely success/failure windows, but cannot prove:

inbound Telegram message_id=1458 -> assistant turn X -> outbound Telegram sendMessage message_id=NNNN succeeded

because outbound delivery logs/hook payloads do not carry the originating inbound id.

Needed runtime patch

• Carry ctxPayload.MessageSid (and ideally chat id/account/session/run id) into the Telegram delivery path.
• Include it in outbound success/failure logs and message_sent hook context, e.g. inboundMessageSid=<id>.
• For overflow/stale-active auto-evacuation, add a runtime-level hook/policy that can short-circuit long main owner-DM work and spawn/link bounded isolated follow-up. Workspace watchdog scripts can only recommend this, not enforce it.

Current safe status

No runtime package files were modified and Gateway was not restarted. Tasks remain blocked until explicit runtime patch/restart approval or upstream support.