Let a child with room to move use its own alignment

`Stack` and `Pad` forced the near edge on every child. That override exists
so a container that reports a child's size and then hands it the box derived
from that report does not place its content twice -- and it is owed only
where the box really is the child's own answer.

`Stack` gives every child the box its sizing child defines. That box is
`box_of(child.size())`, so the sizing child has no room in it and needs the
override; every other child is handed a box that owes nothing to it, and
where it sits in one bigger than itself is its own business. With the
override it could not be aligned at all.

`Pad` reports its inner's size plus the padding, so where its box is that
answer the inset box is exactly the inner and alignment has nowhere to move
it. Where the box is bigger -- a share of a row, a rule over the pad -- the
slack belongs to the inner, and the override pinned it to a corner.

The `tabs` example is the visible case both ways: its counters asked for
`Align::RIGHT` inside a stack and sat at the left, and `text`'s narrow panel
filled a row it had asked to sit at the top of. Both match canonical `main`
again. Neither was noticed when `d3b0ebf` made alignment a property, and the
handoff's claim that `tabs` then "differs only in the widget count it prints
about itself" was wrong -- it was checked at `8220a78` and not re-checked
after the next commit.

Checked: fmt, clippy, 81 suite tests, 17 core unit tests, the release oracle
at 100 seeds and at 1000 seeds of depth 6, and all fifteen shrinker cases at
400 seeds of depth 5. `tabs`, `text` and `random` change exactly where a
child now honours its own alignment; `view` and `minimal` are unchanged.

`tabs` is still not `main`'s render: `.sized((100, 100)).center().width(
leftover(2))` on one widget no longer means a square centred in a two-share
box, because one widget carries one length per axis and `.width` overwrites
what `.sized` set. That one is an API question, not a bug, and is open.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/widget/position/pad.rs

@@ -7,8 +7,14 @@ pub struct Pad {
 
 impl Widget for Pad {
     fn draw(&mut self, painter: &mut Painter) -> Size {
+        // The inner's own alignment, not the near edge. This reports the
+        // inner's size plus the padding, so where the box is that answer the
+        // inset box is exactly the inner and alignment has no room to move
+        // it; where the box is bigger -- a share of a row, a rule over this
+        // widget -- the slack is the inner's to sit in, and forcing the near
+        // edge pinned it to a corner it had not asked for.
         let inner = painter
-            .widget_aligned(&self.inner, self.padding.region(), RegionAlign::NEAR)
+            .widget_within(&self.inner, self.padding.region())
             .size();
         Size {
             x: LayoutLen {

src/widget/position/stack.rs

@@ -29,7 +29,15 @@ impl Widget for Stack {
         let region = painter.box_of(size);
         for (i, child) in self.children.iter().enumerate() {
             painter.child_layer_at(i);
-            painter.widget_aligned(child, region, RegionAlign::NEAR);
+            // The sizing child placed its own content in the box its answer
+            // decided, and this box was derived from that answer, so applying
+            // its alignment again here would place it twice. Every other
+            // child is handed a box that owes nothing to its own answer, and
+            // where it sits in one bigger than itself is its own business.
+            match sizing == Some(i) {
+                true => painter.widget_aligned(child, region, RegionAlign::NEAR),
+                false => painter.widget_within(child, region),
+            };
         }
         size
     }

tests/cases/layout.rs

@@ -499,3 +499,32 @@ fn leftover_children_disappear_at_the_exact_fixed_content_boundary() {
     assert!(h.region(&a).is_none());
     assert!(h.region(&b).is_none());
 }
+
+/// **A stack child smaller than the stack sits where its own alignment
+/// says.** `Stack` gives every child the box its sizing child defines and
+/// used to force the near edge on all of them; that override is owed only to
+/// the sizing child, which has already placed its own content in the box the
+/// stack derived from its answer. Every other child is handed a box that owes
+/// nothing to it, so where it sits in one bigger than itself is its own
+/// business -- and with the override it could not be aligned at all, which is
+/// what moved the `tabs` example's counters to the wrong corner.
+#[test]
+fn a_stack_child_smaller_than_the_stack_keeps_its_own_alignment() {
+    let mut h = Harness::new((400, 200));
+    let big = rect(Color::BLUE).add(&mut h.rsc);
+    let small = rect(Color::RED).sized((50, 50)).add(&mut h.rsc);
+    h.rsc
+        .widgets_mut()
+        .set_alignment(small.id(), Axis::X, AxisAlign::POS);
+    let (a, b) = (big.add_strong(&mut h.rsc), small.add_strong(&mut h.rsc));
+    let children: Vec<StrongWidget> = vec![a, b];
+    h.set_root(Stack {
+        children,
+        size: StackSize::Default,
+    });
+
+    assert_corners!(h, big, (0, 0), (400, 200));
+    // The far edge on X because it asked for it, the middle on Y because
+    // that is the default.
+    assert_corners!(h, small, (350, 75), (400, 125));
+}