[Bug]: wrapping containers in the Flow Graph details pane can render outside their box on Unity 2021.3

[wallstop]

The behaviour

Unity 2021.3 does not resolve a wrapping row's height from the lines it wraps onto. The row keeps a one-line height, and the wrapped lines render outside it - on top of whatever the window draws beneath.

This is measured, not inferred. #438 fixed the Message Monitor's live toolbar by making its box content-sized, which works on 6000.4. The Unity 2021.3.45f1 all modes leg then failed:

TheWrappedLiveToolbarGrowsInsteadOfPaintingOverTheLogHeader
Toolbar control 'dxmessaging-monitor-live-snapshot' renders past the bottom of
the toolbar, so it paints over whatever the window draws beneath it.
  Expected: less than or equal to 61.5f
  But was:  76.0f

The toolbar sat at exactly 40px - its min-height, never grown - while its content needed 76. Both Monitor rows were converted to non-wrapping rows in #438 as a result, because a non-wrapping row's height is its tallest child on every version.

What is left

Ten containers in Editor/Windows/DxMessagingFlowGraphWindow.cs still set flexWrap = Wrap.Wrap:

Line	Container
2466	graph legend
6246	details-pane header
6760	relationship summary row
7112	widest-trace value row
7252	route path flow
7340	details metric grid
7501	details hierarchy trail
7692	relationship header
7706	relationship flow
7789	relationship activity row

Each is followed by siblings in a column, so on 2021.3 a wrapped second line lands on top of the next block. Whether any of them actually wraps depends on content length - type names, trace counts, hierarchy depth - which is exactly the kind of thing that is short in a test fixture and long in a real project.

Why #438 did not fix them

These reflow genuinely variable content, unlike the Monitor toolbar, which was a fixed set of controls that split cleanly into two declared rows. Removing flex-wrap from a metric grid or a hierarchy trail is a redesign of what that block does when it runs out of width, not a deletion.

More importantly it cannot be verified here. The local MCP loop runs against a single host editor (6000.4.6f1), and this defect is invisible on it - the fix that failed on 2021.3 passed 794 EditMode tests locally. Ten unverifiable layout changes at once is how you trade one known defect for several unknown ones.

What a fix needs

1. A 2021.3 editor, or a CI leg that fails on the defect before the change.
2. A decision per container: a declared second row where the content is a fixed set, flex-shrink plus a floor and a clip where it is variable, or a ScrollView where it is unbounded.
3. A layout test per converted container asserting each child stays inside its parent's box at the window's minimum width - the shape TheLiveToolbarRowsStayInsideTheirOwnBoxAtTheWindowsMinimumWidth uses. That assertion is what catches this on the 2021.3 leg, because that is where the second line lands outside.

Worth checking first

Whether this reproduces on 2022.3, which #438's evidence does not cover: that leg passed, but only because nothing in it wrapped, not because the wrap sizing was proven correct.

From #438.

[wallstop]

Fixed in #441, and it was two defects

The wrapping half is as reported. Twelve editor containers now go through
DxMessagingEditorTheme.ApplyContentSizedWrap, which measures the children and gives the container
that height, rather than ten hand-made per-container redesigns. A source and stylesheet scan fails
if anything turns wrapping on by hand again.

The second defect came out of writing the test, and it was live on every editor version, not
just 2021.3. The Monitor's lane pills and active-filter tokens wrapped inside the scroll view's own
content container. Unity sizes that container to the viewport, so:

Shape	Content container	Children need	Scroller range
Wrap on contentContainer (shipped)	72px	105px	0, dead
Wrap on a row the window owns	105px	105px	33

Measured on 6000.4.6f1 with 24 filter tokens in a 72px scroll view. Every token past the first few
lines was unreachable, today, on the current editor.

On "worth checking first: does this reproduce on 2022.3"

Not answered, and worth being exact about why. Proving the original defect on 2022.3 needs a run
of the new containment assertion without the fix, and the branch never had that combination.
What is proved is that with the fix every wrapping container contains its children on 2021.3,
2022.3, 6000.3 and 6000.5.

One related thing did show up on a newer editor. A Flow Graph details header came out ten pixels
short on 6000.3, because Unity reports a geometry change to an element only when that element's
own box changes, and never reports a child's change to the parent, in either propagation phase. A
container already held at a height therefore never heard that its text had finished measuring. So
content-driven growth is not a 2021.3-only concern, even though the original wrap-height defect
may be.

What the cross-version legs caught that one host editor could not

Two real defects in the first version of the fix, both invisible on 6000.4:

• A child laid out with no bound reports Unity's largest length, 8388608. The helper treated that
  as a measurement and asked for a box eight million pixels tall.
• The helper could not hear its own content grow, per the propagation finding above.

Both now have tests that fail without the fix.

Coverage

The 2021.3 symptom is reproduced on any editor by pinning a wrapping row to one line's height,
which is what 2021.3 does on its own. The test runs an unfixed control probe and a fixed probe side
by side: the control leaves its children outside the row, the fixed one does not.