Plugin conformance tests are flaky when CloudWatch logs are not yet visible

## Summary

The `conformance (plugin)` job can fail because expected plugin log records are not returned by CloudWatch, even though the durable execution and history validation complete successfully.

## Evidence

- Previous successful run: `33907972521` at commit `4ce54bcf`.
- Failed run: `33922277509` at commit `676c75a`.
- Attempt 1, job `101185043031`: test `10-11` (`plugin_nested_parent_linkage`) failed because both expected `operation-end` records matched 0 logs: the inner step record and the child-context record.
- Retry attempt 2, job `101188790974`: test `10-11` passed, but unrelated test `10-7` (`plugin_terminal_failure`) failed because its `invocation-start` and `invocation-end` records matched 0 logs.

The failure moving between tests on the same commit strongly suggests CloudWatch ingestion/filter timing or log-stream lookup flakiness rather than a deterministic SDK regression. The diff from the previous successful commit only changes OTel release metadata and does not affect the regular core plugin suite.

## Suggested investigation

- Increase or make configurable the CloudWatch log propagation/polling window in the conformance runner.
- Log the resolved log group, execution ARN filter, event count, and final retrieved records when `ExpectedLogs` fails.
- Pin the conformance runner to a known commit in CI instead of installing `@main`.
- Re-run the plugin suite repeatedly against the same commit to confirm the failure rate.

Relevant workflow: `.github/workflows/conformance-tests.yml`, step `Run conformance suite`.

从 .github/workflows/conformance-tests.yml 和“Run conformance suite”步骤开始，然后针对同一个 commit 反复重新运行 plugin suite。调查 CloudWatch 传播或日志流查找的时序，并记录建议的 log-group、execution-filter、event-count 和 retrieved-record 诊断信息；当 conformance tests 能够可靠地找到预期记录时，即表示完成。

由索引模型根据 Issue 内容生成。