fix(core): constrain the main container of the right-main vertical stack at index 0

enforce_resize_for_right_vertical_stack said "Zero is actually on the right"
but locked top, bottom and right of resize_dimensions[1], so the main
container (index 0, drawn on the right: arrangement.rs primary_left =
area.right - primary_width) was never constrained and the first stack
container could not be resized at all. Index 0 now loses top, bottom and
right (it can only grow to the left); the stack loop over [1..] is unchanged
(nothing in it goes left, first not up, last not down).

The test that pinned the buggy result is replaced by the previously ignored
test of the intended behaviour, un-ignored and extended to 1 to 4 tiles:
[l, rb], [l, rb, tr], [l, rb, trb, tr].

BEHAVIOUR (all three daemons share this function): resizing in the
right-main-vertical-stack layout changes. Gate: Windows e2e resize
scenarios; the ones that run in right-main-vertical-stack are none by name
(resize_commands uses the default layout; layouts.py and commands.py only
tile and cycle through right-main-vertical-stack), so a pointer or
resize-edge scenario in that layout would need adding.

Verified: cargo test -p komorebi-core, with and without --features schemars,
all pass; no e2e run.

crates/komorebi-core/src/workspace.rs

@@ -1378,13 +1378,13 @@ impl<P: WorkspacePlatform> Workspace<P> {
             0 | 1 => self.enforce_no_resize(),
             _ => {
                 // Zero is actually on the right
-                if let Some(left) = resize_dimensions[1].as_mut() {
-                    left.top = 0;
-                    left.bottom = 0;
-                    left.right = 0;
+                if let Some(right) = resize_dimensions[0].as_mut() {
+                    right.top = 0;
+                    right.bottom = 0;
+                    right.right = 0;
                 }
 
-                // Handle stack on the right
+                // Handle stack on the left
                 let stack_size = resize_dimensions[1..].len();
                 for (i, rect) in resize_dimensions[1..].iter_mut().enumerate() {
                     if let Some(rect) = rect {

crates/komorebi-core/tests/resize_constraints.rs

@@ -128,34 +128,21 @@ fn the_ultrawide_stack_has_its_main_column_in_the_middle() {
 }
 
 #[test]
-fn the_right_main_vertical_stack_constrains_index_one_and_leaves_index_zero_free() {
-    // characterization of what the code does: it follows the comment "Zero is actually on the
-    // right" but indexes the second container, so the first (the main one) is never constrained
-    // and the second may not be resized at all; the ignored test below says what the comment asks
+fn the_right_main_vertical_stack_constrains_its_main_container_at_index_zero() {
+    // the main container is index 0 and is drawn on the right (komorebi-layouts arrangement.rs:
+    // primary_left = area.right - primary_width): it may only be resized to the left. The stack
+    // is on the left: nothing in it goes left, the first not up, the last not down.
     check(
         DefaultLayout::RightMainVerticalStack,
         &[
             &[""],
-            &["ltrb", ""],
-            &["ltrb", "", "tr"],
-            &["ltrb", "", "trb", "tr"],
+            &["l", "rb"],
+            &["l", "rb", "tr"],
+            &["l", "rb", "trb", "tr"],
         ],
     );
 }
 
-#[test]
-#[ignore = "bug: enforce_resize_for_right_vertical_stack indexes resize_dimensions[1] where its \
-            comment says zero is on the right; inherited unchanged from the Windows tree"]
-fn the_right_main_vertical_stack_constrains_its_main_container_at_index_zero() {
-    fresh();
-    let mut workspace = workspace_with(DefaultLayout::RightMainVerticalStack, 3);
-
-    workspace.enforce_resize_constraints();
-
-    // the main container is on the right: it cannot go up, down or right
-    assert_eq!(sides(&workspace)[0], "l");
-}
-
 #[test]
 fn layouts_without_a_resize_rule_take_every_adjustment_away() {
     for layout in [DefaultLayout::Grid, DefaultLayout::Scrolling] {