Line a held-back cascade step's message up with its number

[dqnykamp]

Closes #1680.

Rebased onto main now that #1677 (its predecessor, for #1673) has landed, so this diff is its own change alone: the fix, a changeset, two tests, and one qualifying sentence in #1677's still-unreleased changeset.

The bug

A <problem>/<task>/<part> that a <cascade> is holding back has its number drawn a line above the message telling the reader what to finish first:

<problems>
  <cascade>
    <problem><answer>x</answer></problem>
    <problem>
      <cascadeMessage>Answer previous question to continue</cascadeMessage>
      <answer>x</answer>
    </problem>
  </cascade>
</problems>

Problem 2 while problem 1 is unanswered, in headless Chrome at a 1000px-wide viewport. Both columns are measurements, not estimates: the before column comes from a build of this branch with the deleted condition put back.

	before	after
item display	block	grid (32px 818px)
message top, into the item	38px	0px
message margin-top	16px	0px
item height	60px	38px

Cause

SectioningComponent's firstVisibleChild returned null outright whenever hideChildren was set. But a held-back step shows exactly one child: its <cascadeMessage> — the child whose hiding rule is inverted, hidden precisely when everything else is shown, and the reason the childrenToHide test on the next line exists. So the message led nothing: no lead means no useListItemGridLayout, and the item fell back to the layout section.tsx keeps for a number-only item, where the number is an inline-block hung into the start indent by a negative margin and whatever follows it is a block on the next line. The message, keeping its own top margin, was that block.

#1677 already named that test as too broad and pointed at #1680 rather than touching it, because it is a different defect in a different layout path. This PR removes it.

Fix

One condition deleted. childrenToHide is the whole test on its own:

• held back → childrenToHide holds every component child of the step but its title and its message, so the message is the lead, the item numbers itself with the grid layout, and the message's top margin is suppressed;
• revealed → the message is the one thing in childrenToHide and is skipped, so the content behind it leads, exactly as before.

A held-back step that really shows nothing still delegates to nobody without the deleted test: childrenToHide catches its component children, and childIndicesToRender drops its strings.

hideChildren is no longer requested either. Both remaining dependencies, childrenToHide and childIndicesToRender, are computed from hideChildren, and markUpstreamDependentsStale records a potential change on every upstream dependency without comparing values — so a <cascade> holding a step back or letting it go marks this variable stale whichever way the values work out. The new test asserts the transition in both directions rather than leaving it to the argument.

The blast radius is that one line: firstVisibleChild is gated behind nonBoxedListItemWithoutTitle (isListItem && !boxed && !collapsible && titleChildName === null), which is the same condition section.tsx emits the hanging-number grid under, and all four of its consumers — childrenToRenderInlineForListItem, firstVisibleChildAdjustedForListItem, useListItemGridLayout, and firstChildListItemAlignment through the second of those — require that flag too. Within such an item, childrenToHide leaves out only the title (excluded by that gate) and <cascadeMessage>, so the only child a held-back step can newly lead with is a message it is actually showing. A step that is titled or boxed is outside the gate, so it is untouched by construction; measured, it draws its number in a heading of its own — in front of the title, or inside the box header — with the message a line below, which is the ordinary layout for such an item rather than the bug being fixed here.

The suppression lands on the right element in every state, including a <cascadeMessage> that is not its step's first child: the children ahead of it render nothing while the step is held back, so the message is both the core's lead (it gets renderInlineForListItem) and the content wrapper's first element (it gets the > :first-child rule), and the two agree.

No renderer change: cascadeMessage extends P (Aliases.js), so it already declares a listItemInlineAlignment and already consumes renderInlineForListItem for its margin.

Tests

• cascade.test.ts "gives a held-back step's lead to the cascadeMessage it shows": the held-back state (lead is the message, useListItemGridLayout, firstChildListItemAlignment is baseline, margin suppressed), then the same assertions after answering the previous step, where the lead moves to the content and the message becomes the hidden child. It is the mirror of the existing "does not give a list item's lead to a hidden cascadeMessage".
• problem.cy.js "a held-back step's cascadeMessage shares the row with its number": the rendered outcome — margin-top: 0px and the message's top edge on the item's own first row — then verifyUntitledUnboxedListItemUsesGridLayout, the helper this file checks an ordinary untitled unboxed item's numbering grid with, so the grid the item rejoined is pinned and not just its outcome.

Both fail with the condition restored, and nothing else does: cascade.test.ts 16 pass / 1 fail, problem.cy.js 24 pass / 1 fail. With the fix: cascade/sectioning/lists worker suites 93 pass, problem.cy.js 25, list.cy.js 30, sectioning.cy.js 13 (+3 pre-existing pending). Schema regenerates with no diff.

Beyond the two tests, the transition was swept over every shape of held-back step — no children at all, strings only, strings around the message, configuration children only, a title, a composite (<repeat>) child with and without a message, a message after the content, a message alone, a non-rendering <solveEquations> ahead of the content, a hideden message, asList, and a cascade's first step held back, which is reachable when a scoring non-section child such as a bare <answer> precedes it — checking that the lead is never a child whose hidden is true and never stale after the cascade advances. No shape produces either. The reveal was also watched live in a browser: answering step 1 in the page moves step 2's number onto the row of the content that replaces its message, with nothing left stale.

The one line changed outside this fix

.changeset/list-item-hidden-first-child.md is #1677's and is still unreleased, so its entry and this one land in the same CHANGELOG. It said flatly that "a <cascadeMessage> no longer takes the lead", which this release makes false in the held-back half: the sentence is now qualified to the hidden case and points at this entry for the other half.

🤖 Generated with Claude Code