Two fixes:
1. When a parallel branchall/forloop has a `stop_after_all_iters_if` expression
that fails (e.g. bad JS syntax), the error was propagated with `?`, causing
the transaction to roll back the parallel index increment. Since all parallel
jobs were already completed, nothing could ever increment the index again and
the flow hung forever. Now the error is caught and converted to a stop-early
failure so the transaction commits and the flow fails gracefully.
2. Expressions like `results.a.length` in step input transforms resolved to null
because the `handle_full_regex` fast path intercepted them and used
PostgreSQL's `#>` JSON path operator, which can't resolve JS runtime
properties like `.length` on arrays. Now the fast path skips expressions
ending with JS-only properties (like `length`), falling through to full
QuickJS evaluation where they work correctly.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
41e523f827