Greptile Summary

This PR fixes a security-adjacent bug where exec-event heartbeat runs could inadvertently inherit owner-level authorization from the delivery target session. The fix introduces a ForceSenderIsOwnerFalse flag on MsgContext, sets it to true for exec-event heartbeat contexts in heartbeat-runner.ts, and checks it early in resolveCommandAuthorization before any owner-identity or scope resolution.

Key changes:

• src/auto-reply/templating.ts: Adds ForceSenderIsOwnerFalse?: boolean to MsgContext as a trusted internal override
• src/auto-reply/command-auth.ts: Gates senderIsOwner computation on the new flag, effectively clamping it to false for exec-event runs
• src/infra/heartbeat-runner.ts: Sets ForceSenderIsOwnerFalse: hasExecCompletion on the constructed context object so only exec-event (not cron-event or plain heartbeat) runs carry the override
• Tests in both heartbeat-runner test files assert the flag is present and true on the constructed context, and command-control.test.ts verifies senderIsOwner is suppressed end-to-end

The approach is minimal, clearly scoped, and doesn't affect cron-event or plain heartbeat runs. No P0/P1 issues found.

Confidence Score: 5/5

• Safe to merge — the fix is minimal and well-scoped, with no regressions to the non-exec-event paths.
• All findings are P2 or lower. The core logic change is a single ternary guarding senderIsOwner with the new flag, applied before scope and identity resolution. Tests cover both the context-construction side (heartbeat-runner) and the auth-resolution side (command-control). No critical, data, or security issues introduced.
• No files require special attention.

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into fix/heartbeat-c..." | Re-trigger Greptile}