test: add plugin conformance suite handlers (10-1..10-7)

[wangyb-A]

What

7 handlers for the plugin conformance suite (instrumentation-plugin lifecycle hooks) in packages/aws-durable-execution-sdk-python-conformance-tests/handlers/plugin/, plus template_plugin.yaml.

Validation

• Plugin suite is passing, child suite failure not related (fixed in fix: round-trip serdes result on first run across ops #550 )

[github-actions]

Claude AI review

Review — PR #580: plugin conformance suite handlers (10-1..10-7)

No actionable findings. This PR adds test-only conformance handlers plus template_plugin.yaml; it touches no shippable SDK code and cannot regress runtime behavior. I verified the changed handlers against the checked-out SDK sources and they use the public APIs correctly:

• durable_execution(plugins=[...]), DurableInstrumentationPlugin, and the hook-info dataclasses (InvocationStartInfo, InvocationEndInfo, OperationStartInfo/EndInfo, UserFunctionStartInfo/EndInfo) all exist with the fields the handlers read (execution_arn, is_first_invocation, status, operation_id, operation_type, attempt, outcome). InvocationEndInfo.status / UserFunctionEndInfo.outcome are non-nullable in the dataclass, so the is not None guards are defensive but harmless.
• operation_type.name == "STEP" matches OperationType.STEP — correct STEP filtering.
• StepContext.attempt exists and is 1-based; the 10-3 retry handler mirrors the established step/step_with_retry.py (1-11) pattern (RetryStrategyConfig + create_retry_strategy, retryable_error_types=[RuntimeError]).
• RetryPresets.none() (10-7) resolves to max_attempts=1, giving the intended terminal FAILED outcome; StepConfig(retry_strategy=...) signature matches.
• ARN handling is sound: user-function/operation hooks don't carry the ARN, so handlers capture it in on_invocation_start and reuse it, omitting the field when unset rather than inventing one. Replay ordering (10-3: attempt 1 FAILED on first invocation, attempt 2 SUCCEEDED on replay; 10-6: first true→false across the context.wait suspend/replay) is consistent with SDK hook-dispatch semantics.
• Error isolation (10-4) genuinely exercises PluginExecutor._dispatch_plugin's try/except (plugin.py:305-307), which swallows plugin exceptions — matching the guarantee under test.

Residual test risk (considered, not a defect): template_plugin.yaml omits the LoggingConfig: LogFormat: JSON block that template_step.yaml/template_child.yaml carry. This is consistent with the other 6 templates (map/parallel/callback/invoke/wait/wait_for_condition/wait_for_callback also omit it), and the plugin records are emitted as their own top-level JSON via print(json.dumps(...)) with a top-level durableExecutionArn, so a $.durableExecutionArn filter matches without Lambda's JSON log wrapping. The PR reports 7/7 live passes in us-west-2, corroborating this. No change needed, but if the runner ever standardizes on JSON LogFormat, the top-level durableExecutionArn would become nested under message and the scoping filter would need revisiting.

Reviewed commit fee05131e600b8c1a33e2e6af66c82aa3ddcedac. Workflow run

[github-actions]

Codex AI review

No actionable findings found. Residual risk remains around live Lambda/CloudWatch log formatting and the external structured-log matcher, which are not locally covered.

Reviewed commit 2cc14d791f72138468e82501b7bf5ddcfb0c3ba8. Workflow run

[wangyb-A]

re AI review: We use print + json intentionally, since the test runner is filtering the top level durable execution arn, and the plugin does not have access to the context.logger, the test case print the raw json with durable execution arn so that the test runner can discover and validate the log.