TestExprWithFork.ExprWithForkTestCase.test_expr_with_fork_trap is failing intermittently on the Ubuntu main bots

The failures on July 27-28, 2026 are all due to this test failing. For instance:

https://ci.swift.org/view/all/job/llvm.org/view/LLDB/job/lldb-ubuntu-aarch64/job/main/2524

The failure is always:

08:30:18 PASS: LLDB (/workspace/llvm-build/bin/clang-aarch64) :: test_stop_on_fork_set_get (TestExprWithFork.ExprWithForkTestCase.test_stop_on_fork_set_get)
08:30:18 ======================================================================
08:30:18 FAIL: test_expr_with_fork_trap (TestExprWithFork.ExprWithForkTestCase.test_expr_with_fork_trap)
08:30:18 Test that expression evaluation handles a child process that triggers a SIGTRAP.
08:30:18 ----------------------------------------------------------------------
08:30:18 Traceback (most recent call last):
08:30:18 File "/workspace/llvm-project/lldb/test/API/commands/expression/expr-with-fork/TestExprWithFork.py", line 56, in test_expr_with_fork_trap
08:30:18 self.expect_expr(
08:30:18 File "/workspace/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2997, in expect_expr
08:30:18 value_check.check_value(self, eval_result)
08:30:18 File "/workspace/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 348, in check_value
08:30:18 test_base.assertSuccess(val.GetError())
08:30:18 File "/workspace/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 3032, in assertSuccess
08:30:18 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
08:30:18 AssertionError: 'error: Expression execution was interrupted: breakpoint 1.1.
08:30:18 The process has been returned to the state before expression evaluation.
08:30:18 ' is not success
08:30:18 Config=aarch64-/workspace/llvm-build/bin/clang
08:30:18 ----------------------------------------------------------------------
08:30:18 Ran 18 tests in 3.866s
08:30:18
08:30:18 FAILED (failures=1)
08:30:18

BTW, the fact that we report the failure of the expression as the breakpoint that we hit before running the expression is a known issue - we need to replace the original stop reason but we do it too early...

Only one test case out of ~10 in this test is failing, and this was a fairly big patch, so I'm going to disable the test for now.