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」ステップから始め、その後、同じコミットに対して plugin suite を繰り返し実行します。CloudWatch の伝播またはログストリーム検索のタイミングを調査し、提案されている log-group、execution-filter、event-count、retrieved-record の診断情報を取得します。完了の条件は、conformance tests が期待されるレコードを安定して見つけられることです。

索引モデルが issue の本文から書いたものです。