test: make main green again after the schema change route moved to the pool

[datlechin]

Main has been red since #2616. Run 33734073855 failed the unit job and one UI shard, and the unit job did not fail so much as stop: it ran for its full 30 minute timeout and was killed.

Three separate problems, one per commit.

The save runs on a pooled connection now, and one test still watched the session driver

#2616 moved executeSchemaChanges from executionRoute to schemaChangeRoute, which is the metadata route. It updated DatabaseManagerSchemaChangeRoutingTests to seed the pool and left StructureEditingSessionTests behind, so A session applies its staged edits with no view mounted asked the pool to open a connection of its own. No plugin loads under XCTest, so it came back with "MySQL driver plugin not loaded" after ten seconds and every one of the five expectations failed.

The test now seeds a pooled driver on the session's own scope, the same way the routing suite does, and asserts the ALTER landed there with the session driver untouched. That is the behaviour #2616 shipped.

The trigger test raised an alert nobody could answer

Apply and drop run on the pooled connection is the first test to call TriggerEditing.drop end to end. A drop is a .destructiveQuery, so DefaultExecutionGate always confirms it, and AlertOperationConfirming runs an NSAlert. With no window to hang a sheet on, AlertHelper.present falls through to alert.runModal(), which is a nested modal run loop on the main thread. On a headless runner nothing dismisses it. That is where the job stopped: the last test to report was 23 minutes before the timeout killed it.

TriggerEditing.apply and drop now take their gate, defaulting to ExecutionGateProvider.shared, the same shape CompareSyncExecutor already uses. AlwaysAllowGate and AlwaysDenyGate move out of CompareSyncExecutorTests into TableProTests/Helpers so both suites share one.

The Structure segment is under the sidebar on the runner

StructureColumnMoveUITests and StructureTabIdentityUITests both failed twice with the result still on Data. The element tree the failure captured says why: the mode picker reports Data selected with value 1 after the click, and the detail pane's content is laid out 710pt wide starting at x=199 inside a pane that starts at x=354. The runner's screen is 1024x768, and at that width the sidebar, the detail pane and the row inspector do not fit, so the detail content keeps its own width and is drawn under the sidebar. The Structure segment's accessibility frame is where the layout says it is, so XCUITest reports it as hittable and posts the click at (314, 691), which lands on the object browser. Nothing fails there, so the suites went on to read the data grid as though it were the structure grid.

Four suites carried a byte-identical showStructure helper. It moves to UITestCase and drives View > Result View > Structure instead, which has no geometry to be occluded, then waits for the structure tab picker so the switch is observed rather than assumed. The two suites that right-click inside the grid take their point through a new gridPoint(in:of:dy:) that starts from whichever is further right, the grid's leading edge or the object browser's trailing edge.

The underlying layout defect is not fixed here: at 1024pt with the sidebar and inspector open, the detail pane's content overflows both of its neighbours instead of compressing. It is worth its own issue.

Verification

• TableProTests: StructureEditingSessionTests, TriggerApplyExecutionTests, DatabaseManagerSchemaChangeRoutingTests, CompareSyncExecutorTests: 30 executed, 30 passed. No hang.
• TableProUITests: StructureColumnMoveUITests, StructureTabIdentityUITests, StructureConstraintsTabUITests, StructureRowMenuParityUITests: 8 executed, 8 passed. This machine's display is larger than the runner's, so it proves the menu route works, not that the occlusion is gone.

https://claude.ai/code/session_01NdXqgRevM8nxhW8HXhN7aU