The Query Shapes sub-tab assigns a Grid.Row it never declares, so the captured-plans note and grid share a cell #3049

The Activity tab's Query Shapes sub-tab grid in Darling/PerformanceMonitor.Darling.Viewer/ViewerServerTab.xaml declares 10 RowDefinitions and assigns Grid.Row="10".

row   7  DataGrid   PgKernelStatsGrid
row   8  TextBlock  (spacer)
row   9  TextBlock  PgCapturedPlansNote
row  10  DataGrid   PgCapturedPlansGrid   <-- no row 10 exists

Rows 0-9 are declared, so row 10 is out of range. WPF clamps an out-of-range Grid.Row to the last available row rather than throwing, which puts PgCapturedPlansGrid into row 9 together with PgCapturedPlansNote — the note and the grid occupying one cell.

It is the only grid in the file with a row beyond its declarations; every other layout grid in both the SQL Server and PostgreSQL trees is consistent. Two of that block's RowDefinition entries also carry a different indentation from their neighbours, which is the shape of later insertions that added panels without adding the matching rows.

Fix

Add the missing RowDefinition. The neighbouring pairs use Auto for a note and a star height for its grid, so the pattern is already established by the eight rows above it.

Verification this needs

Whatever the fix, it should come with a guard that a layout grid never assigns a Grid.Row at or beyond its own RowDefinition count — the defect is invisible at build time (the XAML compiles and BAML is produced) and only shows up as two controls sharing a cell on screen. A file-wide assertion over the XAML is cheap and would have caught this one.

Not verified

Read from the layout, not observed on screen. The clamping behaviour is WPF's documented handling of an out-of-range Grid.Row; nothing here was rendered, and Darling.Tests cannot execute on macOS. Somebody with a Windows build should confirm the visual overlap before treating the severity as settled — it is possible the note's own margins make the collision unobtrusive.

Provenance

Found while confirming #3048 by parsing the XAML to resolve which TabItem owns the PostgreSQL deadlock grid. Unrelated to that issue's cause and deliberately left out of its fix.