fix(ci): merge-queue tolerance for Build (advisory), drops paid-tier batching

[wgordon17]

Summary

• Restores fix(ci): drop Mergify batch settings (paid-tier feature — queue failed with 'Cannot use Merge Queue batch') #7220's removal of batch_size/batch_max_wait_time (paid-tier Mergify feature, breaks on the free plan) and fix(ci): merge queue tolerates the advisory dast-smoke check #7225's auto-enqueue mechanism (merge_protections_settings.auto_merge_conditions), both silently reverted two weeks ago by Add cliproxy provider exposure controls and manifest injection #7329 (an unrelated cliproxy PR that touched .mergify.yml from a stale branch)
• Retargets the merge-queue's advisory-check exception from dast-smoke to Build (advisory): evidence review showed dast-smoke's hang (fix: dast-smoke 'Build CLI bundle' hangs recurrently on GitHub-hosted runners (24-29min, kills the advisory check) #7226) has been dormant for weeks (0/30 recent runs, 2 failures all-time, none since 2026-07-13), while Build (advisory) (added to quality.yml 2026-07-27) has a 100% failure rate on every sampled PR since, confirmed via job logs to be the same class of runner hang (dies mid-"Creating an optimized production build", never a real compile error) — just in a check the old tolerance never covered
• No PR has used the queue label since Add cliproxy provider exposure controls and manifest injection #7329 landed, so both the original regression and the stale targeting went unnoticed until now

[mergify]

Merge Protections

🟢 Merge protection satisfied — ready to merge.

Show 1 satisfied protection

🟢 📃 Configuration Change Requirements

Mergify configuration change

• check-success = Configuration changed

[diegosouzapw]

Merged — thanks @wgordon17.

Your diagnosis matched an independent measurement I ran while triaging the queue today: of 149 merge-ready candidates, 21 were failing on Build (advisory) and nothing else — Fast Quality Gates, all four Unit Tests shards, Vitest and Merge integrity were green on every one of them. The job log confirms the cause you documented (run 30768479406): Turbopack enters "Creating an optimized production build", runs ~7 minutes, then The runner has received a shutdown signal → The operation was canceled. Never a compile error.

Also appreciated that you dropped the stale dast-smoke exception instead of carrying it forward, and kept the anti-fail-open shape (any other failure still blocks). This unblocks the rest of the queue.