Skip redundant timeout scheduling for completed exports

[skrcode]

This is a small JAIPilot follow-up to your exact current PR head b25a0bbb11c6f4795df05df5399d0aaa38ab4658. It is offered directly to your feature branch so it can become part of open-telemetry#8684; it is not a duplicate upstream PR.

What it changes

applyTimeout() now fast-paths an exporter result that is already complete. The current code creates a wrapper result, schedules a timeout, invokes the completion callback synchronously, and immediately cancels that timeout. The fast path preserves the wrapper's observable success/failure state while avoiding that work. Unfinished exports still use the existing timeout path.

• Production diff: +7 lines in PeriodicMetricReader
• Deterministic effect for a synchronously completed export: 1 timeout schedule/cancel round trip → 0
• Also avoids constructing the timeout wrapper result on that path
• No public API change; no change to ordering or slow-exporter timeout enforcement

Independent verification

I reviewed the complete two-file bot diff and repackaged the byte-identical tree as commit 2e09d7ad45731b752265bc5b0ea82e72041abcd5, whose sole parent is your exact head.

• Baseline focused suite: PeriodicMetricReaderTest — 31 tests, 0 failures
• Candidate focused suite: PeriodicMetricReaderTest — 32 tests, 0 failures
• Baseline: ./gradlew :sdk:metrics:clean :sdk:metrics:build — passed, 161 tasks
• Candidate: same clean module build — passed, 161 tasks, including tests, Spotless, Checkstyle, Animal Sniffer, jApiCmp, and the incubating/debug/JMH-based suites
• git diff --check — passed

The added Mockito test asserts that the scheduler receives zero timeout schedule(...) calls for a synchronous successful export. The original implementation schedules unconditionally.

Scope

This is an operation-count/allocation improvement for exporters that complete synchronously (and for each synchronously completed batch). It is not a blanket wall-clock claim. As in the existing wrapper path, an already-completed exceptional failure is exposed as generic failure, so existing failure behavior is preserved.

Generated by JAIPilot Cloud in skrcode#2, then independently reviewed and rebuilt before this offer.