Generalise `fold_chain_expr` to walk inward through `.object` / `.callee`
and operate at the deepest (= leftmost in source) optional, not just the
outermost element. This fixes nested cases that previously kept their
`?.`:

- `null?.foo.bar` -> `void 0` (collapse — short-circuit at the inner
  `?.foo` skips the outer `.bar`)
- `[]?.foo.bar`   -> `[].foo.bar` (drop the inner `?.`; no other
  optionals remain so unwrap the `ChainExpression`)
- `(foo(), null)?.bar.baz` -> `(foo(), void 0)` (side effects on the
  base preserved via a sequence)

The walk returns one of three outcomes via a small `ChainFoldResult`
enum: `None`, `Flipped`, or `Collapse { base, has_side_effects }`. The
existing nullish/non-nullish logic moves into a single
`try_fold_at_optional` helper that's reused at every chain level.

Reported by armano2 on oxc-project#21923.

Address review notes:

- Extract `is_known_non_nullish` to name the `ValueType` policy. The
  transform's correctness depends on that exact set, so the predicate is
  worth a name to make accidental weakening (e.g. adding `Undetermined`)
  more visible.
- Dedupe the recurse-then-check pattern between
  `try_fold_chain_at_element` and `try_fold_chain_at_expr` via a local
  `recurse_then_fold!` macro. The four match arms in each function
  collapse to one line each.
- Document the iteration interaction with `substitute_chain_expression`:
  nested `ChainExpression`s aren't descended into; the compressor
  flattens them on a later iteration, after which this fold fires.
- Take `&TraverseCtx` (not `&mut`) in `try_fold_at_optional` since it
  only reads context — silences `needless_pass_by_ref_mut`.

Replace the `recurse_then_fold!` macro with explicit per-shape helpers
(`try_fold_call_expression`, `try_fold_member_expression`) and switch
`ChainFoldResult` to `Option<ChainFoldResult>` so the recurse-then-check
shape is expressed with `or_else`/`?` instead of a macro `return`.

Also dedupes the `_has_chain_optional` walkers via
`match_member_expression!`, drops a redundant `&mut` on `TraverseCtx`,
and adds a regression test pinning the nested-`ChainExpression`
flattening behaviour.

After the prior `is_null() || is_undefined()` short-circuit, the only
remaining `ValueType` variants are the concrete types and `Undetermined`,
so `!ty.is_undetermined()` expresses the actual gate ("we know the
concrete type") more directly than enumerating each known variant.

Co-authored-by: armano2 <625469+armano2@users.noreply.github.com>

Spell out why only the outer `?.` flips: the inner stays optional
because `Identifier("Number")` resolves to `Undetermined`, while the
outer's base `Number.POSITIVE_INFINITY` has a known `value_type`.