ci: run e2e tests on otel-plugin changes

[hln33]

Issue Link, if available

N/A

Description

The e2e-tests workflow's paths filter omitted otel-plugin/, so any PR touching only that module (including real code changes, not just dependency bumps) silently skipped e2e coverage. Add 'otel-plugin/**' to the paths filter on both the pull_request and push triggers.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Demo/Screenshots

N/A

Checklist

• I have filled out every section of the PR template
• I have thoroughly tested this change

Testing

Unit Tests

Have unit tests been written for these changes? N/A

Integration Tests

Have integration tests been written for these changes? N/A

Examples

Has a new example been added for the change? (if applicable) N/A

[github-actions]

Codex AI review

No actionable findings. The symmetric path additions correctly trigger E2E tests for otel-plugin/** changes. Residual risk is limited to GitHub Actions trigger behavior, which has no repository-level test coverage.

Reviewed commit 8278c586b78fedf6815e66957bec1b25feb21a01. Workflow run

[github-actions]

Claude AI review

This PR adds 'otel-plugin/**' to the paths filter on both the pull_request and push triggers of .github/workflows/e2e-tests.yml, so PRs touching only the otel-plugin module now trigger E2E coverage.

The change is correct and well-scoped:

• The examples/ module depends on aws-durable-execution-sdk-java-plugin-otel (examples/pom.xml), and the E2E job explicitly runs CloudBasedOtelIntegrationTest (e2e-tests.yml:97), so otel-plugin changes can genuinely alter E2E results — the omission the PR fixes was real.
• The new entry is placed consistently within the existing module list on both triggers and preserves valid YAML.
• The filter is only broadened (never narrowed), so no previously-covered path loses coverage.

No correctness, API-compatibility, replay/checkpoint, concurrency, logging, or serialization concerns apply to a two-line YAML paths addition. The "N/A" test answers in the PR are appropriate, since a paths filter is not meaningfully unit-testable.

No actionable findings.

Residual test risk: paths-filter behavior is only validated by observing which workflows trigger on future PRs; there is no automated check that the filter list stays in sync with the set of modules the E2E job actually builds/deploys, so future module additions could reintroduce a similar gap.

Reviewed commit 8278c586b78fedf6815e66957bec1b25feb21a01. Workflow run

[ayushiahjolia]

Nice, I was going to cover this in #630