fix(source-control): judge native lane auto-merges without a pin read-back #9447

Refs: #9276

Problem

A lanes App pull request merged by GitHub's native auto-merge (#9399) has no <!-- babysit-merge-pin sha=... --> comment, because only babysit_merge.py posts that comment before it enqueues. The post-merge check is likely to judge such a merge as the lane's own and then fail it:

• Who enqueues. The account that enables auto-merge becomes the enqueuer. On feat(source-control): hold only the takeover set on the babysit HIGH floor #9413 a person armed auto-merge, and its AddedToMergeQueueEvent has that person as both actor and enqueuer. When enable-auto-merge.mjs arms with the lanes App token, the enqueuer should be the App, so derive_auto_merge marks the merge by_identity (babysit_merge_policy.py:2742).
• What the check does then. babysit_postmerge._judge sees by_identity with no pin. It reports read-back-unrecorded until the dispatch deadline and a read-back failure after it (babysit_postmerge.py:1492-1506).
• What follows. A failure files a demotion record. The unverified merge also keeps counting toward max-in-flight. Both hold the pr-merge gate for the pull requests it still gates: adopted owner PRs and Dependabot's.

UNVERIFIED: no lanes App pull request has merged natively yet. Merges #9401, #9395 and #9392 all went through the gate's own enqueue.

Done when

• A native lane merge (one with an AutoMergeEnabledEvent by the agent identity) passes the post-merge check on the dispatch and canary runs, with no pin read-back required.
• It is still judged by identity, so post-merge-dispatch starts its full run.
• No extra API call. The auto-merge event comes from the same GraphQL request, through a second aliased timelineItems connection. It is not added to the existing last:1 queue-event connection, because derive_auto_merge reads events[-1] as the queue event.