[Feature]: Testing SDK support for invoking callbacks by callback ID without requiring operation name or index

### What would you like?

Currently, the `LocalDurableTestRunner` requires knowledge of operation names or indices to interact with callback operations. When using `getOperation()`, `getOperationByIndex()`, or `getOperationByNameAndIndex()`, the caller must have prior knowledge about the operation's position or name in the execution flow.

This creates a coupling problem for implementations that need to invoke callbacks on a local machine (outside of unit tests) where the invoking code shouldn't need to know the internal details of the Lambda function being invoked.

Specifically, when building let's say `LocalLambdaInvoker` implementation that handles callback invocations, the invoker receives only the callback ID from the durable execution service but has no knowledge of:
* The operation name assigned by the developer
* The operation's index in the execution sequence
* The operation's internal ID

When running durable functions locally (not in unit tests), there's a need to invoke callbacks from external systems that only have access to the callback ID. The current API forces these systems to maintain additional metadata about operation names and indices, which:
Creates unnecessary coupling - The local invoker must understand the internal structure of the Lambda function
Breaks encapsulation - Implementation details (operation names/indices) leak to external systems
Increases complexity - Requires additional bookkeeping to map callback IDs to operation names/indices
Limits flexibility - Makes it difficult to build generic local execution infrastructure.

### Possible Implementation

Add a new method `getOperationByCallbackId(callbackId: string)` to the `LocalDurableTestRunner` that allows retrieving operations using only the callback ID.

This method should:
* Search through all operations to find one with a matching callback ID
* Return a DurableOperation that can be used with existing methods (sendCallbackSuccess, sendCallbackFailure, sendCallbackHeartbeat)
* Follow the same pattern as existing getOperationBy* method

### Is this a breaking change?

No

### Does this require an RFC?

No

### Additional Context

Example:
```
// Current approach - requires knowing operation details
const operation = runner.getOperation("my-callback-operation");
await operation.sendCallbackSuccess("result");

// Proposed approach - works with only callback ID (as received from service)
const operation = runner.getOperationByCallbackId("callback-abc-123");
await operation.sendCallbackSuccess("result");
```

Start at LocalDurableTestRunner and read the existing getOperation(), getOperationByIndex(), and getOperationByNameAndIndex() methods to follow their lookup and return patterns. Add callback-ID lookup across the operations, then verify that the returned DurableOperation supports the existing callback success, failure, and heartbeat methods.

Written by the indexing model from the issue text.