[Feature]: Custom subtype for step, callback, and child context operations #757

What would you like?

Let a caller set a custom subtype on a step, a callback, and a child context.

1. A function can compose several durable operations into one larger operation. [Feature]: Add a public API for custom extension operations #571 proposes a public API for such extension operations.
2. Every operation records a subtype in its checkpoint. Execution history and plugins read it.
3. In Java, the subtype always comes from the OperationSubType enum. StepConfig, CallbackConfig, and RunInChildContextConfig have no subtype option. The overload of runInChildContextAsync that takes a subtype is private.
4. So the parts of an extension operation all record Step, Callback, or RunInChildContext. History and plugins can tell them apart only by parsing their names.

The JS SDK supports this today: ChildConfig.subType, and since aws/aws-durable-execution-sdk-js#939, StepConfig.subType and CreateCallbackConfig.subType. The Go SDK has WithChildSubType.

Possible Implementation

1. Add an optional subType(String) to the builders of StepConfig, CallbackConfig, and RunInChildContextConfig.
2. OperationIdentifier holds an OperationSubType, and derives the operation type from it. A custom subtype is a string with no enum value. So the identifier needs the operation type and the subtype string as separate fields. The enum stays as the source of the default subtypes.
3. Use the custom subtype everywhere the default is used today: checkpoint updates, replay validation, and plugin info (OperationInfo and the classes built by PluginInfoConverter).
4. Validate the value before the operation is created:
   • A null or empty value selects the default.
   • The service accepts 1 to 32 characters from [a-zA-Z0-9-_]. It rejects any other subtype with HTTP 400 ValidationException, and the execution then fails. So the SDK should reject such a value with a clear error.
   • Optionally reject the values the SDK uses for its own operations, as the Go SDK does.
5. Optionally, make the local runner in sdk-testing reject an invalid subtype with the service's message, as the JS testing SDK does since feat(sdk): add subType to step and createCallback aws-durable-execution-sdk-js#939.

Nothing in the SDK decides how to suspend or retry from the subtype. So no other logic needs to change.

Is this a breaking change?

No. Without the option, the SDK records the same subtypes as today. The OperationIdentifier change in step 2 touches internal types only.

Does this require an RFC?

No.

Additional Context

• Replay compares the subtype with the checkpoint. So changing a subtype is a breaking change for executions in flight. The option's Javadoc should say this.
• [Feature]: Add SubType for #396 added fixed subtypes to every operation. This issue adds caller-chosen ones on top.