Checkpoint derived operation names for composite handlers instead of passing them via internal plugin-only channel

`waitForCallback`'s inner CALLBACK and submitter STEP are created without a name, so plugins can't label their spans meaningfully. As a workaround, DurableContextImpl exposes internal `_createCallbackWithPluginOperationName / _stepWithPluginOperationName` methods that forward a derived name (-callback, -submitter) to instrumentation plugins only, via a dedicated parameter - never checkpointed, never part of the public StepConfig/CreateCallbackConfig types.

This workaround exists because checkpointing the derived name today would change the Name field for operations that existing in-flight executions already checkpointed as undefined, breaking replay validation.

In the next breaking release, change the operation handler signature so createCallback/step can accept and checkpoint a name supplied by an internal caller like waitForCallback, and have plugins read the name directly from the checkpointed operation instead of a side-channel parameter. This removes InternalDurableContext, the _*WithPluginOperationName methods, and the pluginOperationName handler parameter, simplifying the code path and matching how Java/Python SDKs already handle this (they pass the derived name straight into the checkpoint call).

**Why not now:** Requires a breaking change to checkpoint format / replay compatibility for in-flight executions.

Start at waitForCallback and trace createCallback/step through the handler signatures and checkpointing path. Review InternalDurableContext, the _*WithPluginOperationName methods, and the pluginOperationName parameter, then compare the Java/Python SDK behavior mentioned in the issue. Done means derived names are checkpointed, replay compatibility is handled for the breaking release, and the side channel is removed.

Written by the indexing model from the issue text.