[Feature]: Testing SDK to make testing callbacks easier

### What would you like?

Testing callbacks with the local runner is awkward right now because:
1) You can't just run the execution with `await runner.run({ payload: ... })` because it'd hang while waiting for the callback. So you have to start the execution, sleep for a reasonable amount of time for the execution to reach the callback, then get the callback operation so you can send the success or failure response.
2) There's no real way to test callback timeouts because `skipTime: true` only works on wait operations, not callbacks. If your handler code distinguishes timeouts from other errors (e.g. a failure response from callback) then you can't skip the wait time.

### Possible Implementation

To address problem 1, I want to be able to do something like this, to provide the callback when requested:

```
const execution = await runner.run({
payload: { orderId, restaurantName: 'Fangtasia' },
callbacks: {
"": async (calbackId, callbackOp) => {
callbackOp.sendCallbackSuccess(JSON.stringify({ ... })
}
}
})
```

That way, I can run the execution to the end, and then inspect the steps afterwards.

For problem 2, maybe `skipTime` could skip the wait time for callbacks as well, if:
a) a callback delegate is given, or
b) the delegate function didn't send a success or failure response

### Is this a breaking change?

No

### Does this require an RFC?

No

### Additional Context

_No response_

Start with the testing SDK's local runner entry point, especially runner.run, callback operations, and the skipTime option. Trace how callback requests currently pause execution and how success, failure, and timeout outcomes are represented. Done means runner.run can accept callback delegates, complete without manual sleeps, and support deterministic callback-timeout testing.

Written by the indexing model from the issue text.