fix: break container instead of expanding one of many object siblings (#641)

Previously `const a = [{...}, {...}, {...}, {...}];` could format as

  const a = [{...}, {...}, {...}, {
    longest,
  }];

— a single sibling was promoted to inline multi-line while the others
stayed inline. dprint's resolver does this whenever every value passes
`allows_inline_multi_line` (issue #641).

Adjust `gen_separated_values_with_result`: precompute the
inline-multi-line flags, then count siblings that would actually
compete for the slot — ignoring arrow/function-expression candidates,
which are the canonical prettier-style hugging shape
(`Array.from(x, () => { … })`, `foo(arg, () => {})`). If two or more
non-arrow siblings remain, none get inline-multi-line, so the resolver
breaks the container.

This aligns the array-of-objects layout with prettier:

  const a = [
    { name: "FPN" },
    { name: "FPN Class" },
    …
  ];

The change also applies to function-call arguments and tuple types,
keeping behavior consistent across all `gen_separated_values`
consumers.

Spec updates (existing snaps that pinned the old hugging shape):
- specs/expressions/ArrayExpression/ArrayExpression_PreferSingleLine_True.txt
- specs/issues/issue0520.txt  (large nested-JSON snapshot)
- specs/issues/old_repo/issue067.txt
- specs/types/TupleType/TupleType_PreferSingleLine_True.txt

Last-arg arrow hugging (issue0312) is preserved by the new
`is_function_hugging_candidate` helper that drops arrow/fn siblings
from the count.

New spec: specs/issues/issue0641.txt covering the regression, the
preserved arrow-hugging behavior, the single-object-hugging behavior,
and tuple-of-types / array-of-arrays variants. Patterns
cross-referenced against prettier's tests/format/js/arrays fixtures.

Author: todor-a

src/generation/generate.rs

@@ -7912,6 +7912,26 @@ fn gen_separated_values<'a>(opts: GenSeparatedValuesParams<'a>, context: &mut Co
   gen_separated_values_with_result(opts, context).items
 }
 
+/// True when the value is an arrow / function expression (possibly wrapped in
+/// ExprOrSpread / ParenExpr). These are the prettier-style "last arg hugging"
+/// candidates that should keep inline-multi-line privileges even when there are
+/// other siblings that could also expand inline.
+fn is_function_hugging_candidate(value: &NodeOrSeparator) -> bool {
+  fn is_arrow_or_fn(expr: Expr) -> bool {
+    match expr {
+      Expr::Arrow(_) | Expr::Fn(_) => true,
+      Expr::Paren(paren) => is_arrow_or_fn(paren.expr),
+      _ => false,
+    }
+  }
+  match value {
+    NodeOrSeparator::Node(Node::ArrowExpr(_)) | NodeOrSeparator::Node(Node::FnExpr(_)) => true,
+    NodeOrSeparator::Node(Node::ExprOrSpread(e)) => is_arrow_or_fn(e.expr),
+    NodeOrSeparator::Node(Node::ParenExpr(p)) => is_arrow_or_fn(p.expr),
+    _ => false,
+  }
+}
+
 fn gen_separated_values_with_result<'a>(opts: GenSeparatedValuesParams<'a>, context: &mut Context<'a>) -> GenSeparatedValuesResult {
   let nodes = opts.nodes;
   let separator = opts.separator;
@@ -7931,15 +7951,34 @@ fn gen_separated_values_with_result<'a>(opts: GenSeparatedValuesParams<'a>, cont
       let is_multi_line_or_hanging = is_multi_line_or_hanging_ref.create_resolver();
       let mut generated_nodes = Vec::new();
       let nodes_count = nodes.len();
+      let inline_multi_line_flags: Vec<bool> = nodes
+        .iter()
+        .map(|value| match value {
+          NodeOrSeparator::Node(v) => allows_inline_multi_line(*v, context, nodes_count > 1),
+          _ => false,
+        })
+        .collect();
+      // Count siblings that would compete for an inline-multi-line slot, but
+      // ignore arrow/function-expression last-arg "hugging" candidates — those
+      // are the canonical `Array.from(x, () => { ... })` / `foo(arg, () => {})`
+      // shape that prettier keeps single-line at the call level. Without this
+      // exclusion the array-of-objects fix from issue #641 would regress the
+      // last-arrow-arg case.
+      let inline_multi_line_count = nodes
+        .iter()
+        .zip(inline_multi_line_flags.iter())
+        .filter(|(value, flag)| **flag && !is_function_hugging_candidate(value))
+        .count();
+      let allow_any_inline_multi_line = inline_multi_line_count <= 1;
 
       for (i, value) in nodes.into_iter().enumerate() {
         let node_index = match &sorted_indexes {
           Some(old_to_new_index) => *old_to_new_index.get(i).unwrap(),
           None => i,
         };
-        let (allow_inline_multi_line, allow_inline_single_line) = if let NodeOrSeparator::Node(value) = value {
-          let is_last_value = node_index + 1 == nodes_count; // allow the last node to be single line
-          (allows_inline_multi_line(value, context, nodes_count > 1), is_last_value)
+        let (allow_inline_multi_line, allow_inline_single_line) = if let NodeOrSeparator::Node(_) = value {
+          let is_last_value = node_index + 1 == nodes_count;
+          (allow_any_inline_multi_line && inline_multi_line_flags[i], is_last_value)
         } else {
           (false, false)
         };

tests/specs/expressions/ArrayExpression/ArrayExpression_PreferSingleLine_True.txt

@@ -33,19 +33,22 @@ const a = [
     ["123456", "123456"], //
 ];
 
-== should not be multi line if the objects are allowed to be inline multi-line ==
+== should break the container when multiple object siblings could each go inline multi-line (issue #641) ==
 const t = [{
     prop: 5
 }, {
     other: "string"
 }];
 
 [expect]
-const t = [{
-    prop: 5,
-}, {
-    other: "string",
-}];
+const t = [
+    {
+        prop: 5,
+    },
+    {
+        other: "string",
+    },
+];
 
 == should maintain blank lines when exceeding the line width ==
 const t = [