[Bug]: waitForCondition exhaustion can produce FAILED invocation without ErrorObject

### Expected Behavior

When `waitForCondition` exhausts its configured attempts, the SDK should:

1. Checkpoint the `WaitForCondition` step as `FAILED` with a non-null `ErrorObject`.
2. Checkpoint an enclosing synchronous child context as `FAILED` with a non-null `ErrorObject`.
3. Return a root `DurableExecutionInvocationOutput` with `Status=FAILED` and a non-null `ErrorObject`.

This ensures replay preserves useful diagnostics and any service/emulator consuming the invocation result can reliably record the execution as failed.

### Actual Behavior

The built-in wait strategies throw `WaitForConditionFailedException(String)`, whose `DurableOperationException` state has a null `ErrorObject`.

That null propagates through the failure path:

- `WaitForConditionOperation.handleCheckFailure()` reuses `DurableOperationException.getErrorObject()` without a null fallback.
- `ChildContextOperation.handleChildContextFailure()` does the same.
- `DurableExecutor.buildErrorObject()` returns `DurableOperationException.getErrorObject()` directly, even when it is null.

The final invocation output can therefore be equivalent to:

```json
{
"Status": "FAILED"
}
```

The Java `LocalDurableTestRunner` preserves the `FAILED` status, but the error is absent. When used through SAM Local, this combines with an emulator bug that currently converts `FAILED` with no error into `ExecutionSucceeded`.

### Steps to Reproduce

Use a synchronous child context containing a condition that never stops polling:

```java
var runner = LocalDurableTestRunner.create(String.class, (input, ctx) ->
ctx.runInChildContext("child", String.class, child ->
child.waitForCondition(
"poll",
String.class,
(state, stepCtx) -> WaitForConditionResult.continuePolling(state),
WaitForConditionConfig.builder()
.waitStrategy(WaitStrategies.fixedDelay(
2, Duration.ofSeconds(1)))
.build())));

var result = runner.runUntilComplete("test");
```

The local runner reports `FAILED`, but the root error is absent. Running the equivalent handler through SAM Local can produce this history:

```text
StepFailed (WaitForCondition)
ContextFailed (RunInChildContext)
InvocationCompleted
ExecutionSucceeded
```

### SDK Version

`2.1.0`; the behavior is also present on current `2.1.1-SNAPSHOT` / `main` as of 2026-08-19.

### Java Version

17

### Is this a regression?

No known working version.

### Last Working Version

N/A

### Proposed Fix

Always fall back to serializing the thrown exception when an SDK exception has no embedded error:

```java
if (e instanceof DurableOperationException operationException
&& operationException.getErrorObject() != null) {
return operationException.getErrorObject();
}
return ExceptionHelper.buildErrorObject(e, serDes);
```

Apply equivalent null fallbacks when checkpointing failures in `WaitForConditionOperation` and `ChildContextOperation`, so operation history and replay also retain the error.

Add an integration test for max-attempt exhaustion inside synchronous `runInChildContext` that asserts:

- the step is failed with error details;
- the child context is failed with error details;
- the root invocation is `FAILED` with an error.

### Related Issue

The SAM Local emulator status-handling defect exposed by this null error is tracked in aws/aws-durable-execution-sdk-python#656.

Bắt đầu với WaitForConditionOperation.handleCheckFailure(), ChildContextOperation.handleChildContextFailure() và DurableExecutor.buildErrorObject(), sau đó chạy việc tái hiện runInChildContext đồng bộ bằng LocalDurableTestRunner. Thêm các fallback cho lỗi null và một integration test bao quát trường hợp đã dùng hết số lần thử tối đa. Được xem là hoàn tất khi step, child context và root invocation đều ở trạng thái FAILED với thông tin chi tiết về lỗi.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.