Evergreen: always merge main first, then fix CI as separate pushes

[Copilot]

Evergreen treated merge_conflict and failing_checks as independent issues, so a CI-fix run could include a local main merge in its patch and conflict with the un-merged remote PR branch on push_to_pull_request_branch. This change makes "merge main first" an explicit, separate push that always precedes any CI fix.

Selector (pr_needs_attention)

• New get_behind_by() helper hits GET /repos/{repo}/compare/{base}...{head} and reads behind_by.
• Adds a behind_main: N commit(s) issue type so PRs behind main are picked up even when CI is green. Suppressed when merge_conflict is already flagged (the merge step covers both).

Workflow prompt

Replaces the two ad-hoc subsections with an ordered 5-step flow:

1. If merge_conflict or behind_main, git fetch origin main + git merge origin/main, resolve, run local checks.
2. Push Build tsb: pandas → TypeScript migration #1 — merge commit only, via push-to-pull-request-branch.
3. Re-check CI on the new HEAD; drift-only failures end here.
4. If still red: diagnose, fix, Push [Autoloop] [Autoloop: build-tsb-pandas-typescript-migration] #2 — fix commit only.
5. Update repo-memory tracking + PR comment (mention both pushes when applicable).

Rules

• New rule: always merge main as its own push; never bundle a main merge into a CI-fix patch — that's what causes the patch conflict.
• New rule: one concern per push (merge push = merge only; fix push = fix only).
• Tracking rule extended so a clean merge-only push also counts as success and resets the attempt counter.

evergreen.lock.yml regenerated via gh aw compile.