fix: remove unused async options from Reactor.undo/3 (#292)

`Reactor.undo/3` accepted async-related options (`async?`, `max_concurrency`,
`timeout`, `max_iterations`) but never used them. The undo operation is
intentionally sequential - this is correct saga behaviour as the forward
dependency graph cannot be reliably inverted for undo operations.

This is a breaking change: passing removed options will now result in a
Spark.Options validation error.

Also fixes a flaky timing test in executor_test.exs by removing an
unnecessarily tight upper bound on elapsed time.

Closes #291

Author: jimsynz

lib/reactor.ex

@@ -126,15 +126,7 @@ defmodule Reactor do
             | fully_reversible_option
           )
 
-  @type undo_options ::
-          Enumerable.t(
-            max_concurrency_option
-            | timeout_option
-            | max_iterations_option
-            | halt_timeout_option
-            | async_option
-            | concurrency_key_option
-          )
+  @type undo_options :: Enumerable.t(concurrency_key_option)
 
   @type state :: :pending | :executing | :halted | :failed | :successful
   @type inputs :: %{optional(atom) => any}
@@ -253,11 +245,29 @@ defmodule Reactor do
     end
   end
 
-  @undo_options Keyword.drop(@run_schema, [:fully_reversible?])
+  @undo_options [
+    concurrency_key: [
+      type: :reference,
+      required: false,
+      hide: true
+    ]
+  ]
 
   @doc """
   Attempt to undo a previously successful Reactor.
 
+  Undo operations are always executed sequentially in reverse completion order.
+  This is intentional: while the forward execution graph captures data
+  dependencies between steps, it cannot capture the full set of constraints
+  that may apply during rollback. A step's undo logic may have side effects
+  that affect other steps in ways not expressed in the original dependency
+  graph, or external systems may have ordering constraints during rollback
+  that differ from forward execution.
+
+  Since undo operations are expected to be infrequent (only triggered on
+  explicit reversal requests), sequential execution is an acceptable trade-off
+  that ensures predictable rollback behaviour.
+
   ## Arguments
 
   * `reactor` - The previously successful Reactor struct.

lib/reactor/step/compose.ex

@@ -39,11 +39,8 @@ defmodule Reactor.Step.Compose do
 
   @doc false
   @impl true
-  def undo(%{reactor: reactor}, _args, context, options) do
-    Reactor.undo(reactor, context,
-      concurrency_key: context.concurrency_key,
-      async?: options[:allow_async?]
-    )
+  def undo(%{reactor: reactor}, _args, context, _options) do
+    Reactor.undo(reactor, context, concurrency_key: context.concurrency_key)
   end
 
   def schedule_undoable_reactor_run(context) do

test/reactor/executor_test.exs

@@ -357,7 +357,7 @@ defmodule Reactor.ExecutorTest do
           assert {:ok, _} = Reactor.run(SleepyReactor, %{}, %{}, async?: false)
         end)
 
-      assert elapsed >= 500 and elapsed <= 600
+      assert elapsed >= 500
     end
 
     test "it can be run asynchronously" do