Exercise 1: A Lone Inline Element Never Reaches the Grouping Logic — Possible Solution
====================================================================

THE TEST
------------------------------
    span_node = a StyledNode for <span>just text</span>
                (display: inline, one text child)

    span_box = build_layout_tree(span_node)
    span_box.box_type
    [c.box_type for c in span_box.children]

RESULT
------------------------------
    span_box.box_type -> 'inline'
    child box_types   -> ['inline']

Both the <span> itself and its own text child come out as plain
'inline' boxes, with no anonymous wrapping applied anywhere.

WHY THIS CASE NEVER REACHES THE GROUPING LOGIC
------------------------------
build_layout_tree's own first real decision is:

    box_type = display_type(styled_node)
    box = LayoutBox(box_type, styled_node)

    if box_type != 'block':
        for child in styled_node.children:
            box.children.append(build_layout_tree(child))
        return box

display_type(span_node) returns 'inline' (a <span>'s own computed
display, per the UA stylesheet). Since box_type != 'block' is True
here, the function takes the EARLY RETURN branch -- it loops over the
span's own children and recurses on each one plainly, then returns
immediately. The entire pending_inline / flush() grouping mechanism
that appears further down in the function is only ever reached for a
box whose own box_type IS 'block' -- an inline box's body never
executes that code at all, structurally, not just because there
happens to be nothing to group in this particular example.

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms grouping is specifically a BLOCK box's own responsibility
for its own direct children, not a universal rule applied everywhere in
the tree. An inline box like <span> can itself contain further inline
content (more text, nested inline elements) without ever needing an
anonymous wrapper, because inline-in-inline nesting doesn't violate the
invariant this chapter cares about -- that invariant is specifically
about a BLOCK box never having a raw inline child, and <span> here
isn't a block box at all, so the concern the whole mechanism exists to
address simply doesn't apply to it.