Add plugin conformance case 10-14 (known SDK gap)

[wangyb-A]

Summary

Test case for #579

[github-actions]

Codex AI review

No actionable findings.

Residual risk: conformance case 10-14 remains intentionally failing until OperationEndInfo exposes successful operation results.

Reviewed commit 81a1e93670b4e101cfdb5a3c211d1525c20a830b. Workflow run

[github-actions]

Claude AI review

No actionable findings.

This PR adds one conformance handler (conformance-tests/src/main/java/plugin/PluginTerminalPayloads.java) plus its CloudFormation entry in template_plugin.yaml. I verified every claim the PR relies on against the base revision:

• API gap is real and accurately documented. OperationEndInfo (sdk/src/main/java/software/amazon/lambda/durable/plugin/OperationEndInfo.java:24-35) is exactly the 11-field record the JavaDoc describes and exposes no serialized-result accessor, so logging result: NONE for the successful step is an honest report of the gap.
• Error path works as claimed. BaseDurableOperation.fireOnOperationEnd → extractErrorFromOperation → DurableOperationException, whose message is errorObject.errorMessage(). For RuntimeException("boom") under NO_RETRY, info.error().getMessage() yields boom; for the successful step error() is null, so the null-guard on line 71-73 correctly falls back to NONE.
• Hook firing and filtering are correct. onOperationEnd fires for both terminal steps (SUCCEEDED and FAILED); PluginSupport.isStep(info.type()) filtering matches the sibling handlers.
• Wiring is complete and consistent. The YAML entry's indentation, Handler: plugin.PluginTerminalPayloads, role, and DurableConfig match the existing entries; all imports are used; no other registration point exists.
• JSON assembly matches suite convention. Direct string interpolation without escaping mirrors ConformanceLoggingPlugin/PluginRetryExhaustion; all interpolated values here are controlled literals, so no malformed output.

Residual test risk (by design, not a defect): This handler is intentionally red — the SUCCEEDED result: "task-a" assertion will fail until a result() accessor is added to OperationEndInfo. Note two dependencies worth watching: (1) the error: boom assertion depends on SDK serialization preserving the raw exception message with no type prefix (unlike StepFailedException, which prepends the type); if the checkpointed errorMessage ever changes format, this branch's expectation would drift. (2) There is no local/unit test accompanying the handler — it is validated only via the cloud conformance suite — which is consistent with the other handlers in this package.

Reviewed commit 81a1e93670b4e101cfdb5a3c211d1525c20a830b. Workflow run