Startup hang: snap-to-grid loop spins forever in WM_GETMINMAXINFO while persisted panes are still being created #20859

Windows Terminal version

1.25.2733.0 (also the portable zip)

Windows build number

10.0.26300.9711

Other Software

TrueCrypt volume holding the tabs' starting directories.

Steps to reproduce

1. "firstWindowPreference": "persistedLayout", snapToGridOnResize at its default (on).
2. Use the attached state.json (4 windows, 44 tabs, 41 splits, all cmd.exe), with startingDirectory pointed at a folder on a slow volume. Mine is an encrypted TrueCrypt drive.
3. Launch Terminal a few times; it is a race. 3 of 5 launches hung for me, none with the same layout on C:.

Expected Behavior

The layout restores.

Actual Behavior

The UI thread spins at 100% CPU indefinitely after 6-7 panes have started, and later wt.exe launches are handed to the hung process. Stack of the spinning thread:

TerminalApp!Pane::_CalcSnappedChildrenSizes+0x6b
TerminalApp!Pane::_CalcSnappedDimension+0x114e21
TerminalApp!Pane::CalcSnappedDimension+0x1c
TerminalApp!winrt::TerminalApp::implementation::TerminalPage::CalcSnappedDimension+0x98
WindowsTerminal!IslandWindow::_OnGetMinMaxInfo+0xa5
WindowsTerminal!IslandWindow::MessageHandler+0x4b2
...
win32u!NtUserShowWindow+0x14
WindowsTerminal!AppHost::_WindowInitializedHandler$_ResumeCoro$1+0x217

Likely cause: a control that has not been initialized yet reports a cell width of 0 (_actualFont starts at { 0, DEFAULT_FONT_SIZE }), so _AdvanceSnappedDimension adds 0 and the while (sizeTree.size < fullSize) loop never ends. Unchanged on main. Guarding against a zero grid unit should fix it.

Workaround: "snapToGridOnResize": false (0 of 5 hangs vs 2 of 5 with it on).

Probably the same hang as #18610. My #20765 blamed persisted buffers; that was wrong, this is the cause.