`PeriodicMetricReader#shutdown` should include effects of `force_flush`

Per open-telemetry/opentelemetry-specification#2983 and its fix, open-telemetry/opentelemetry-specification#5305, the metrics spec would require the periodic exporting MetricReader to collect and export whatever metrics were recorded since the last periodic tick before the underlying exporter is shut down.

I'm not experienced in opentelemetry-ruby or its codebase, but the following AI-assisted analysis seems to confirm PeriodicMetricReader.Shutdown doesn't currently do this a deterministic way:

• shutdown signals the background thread to stop by setting @continue = false and calling @condition.signal.
• If the background thread is idle, waiting on @condition.wait (the common case), it wakes up, runs one more export, which calls collect, and only then re-checks @continue and exits the loop. In this case the final collect does happen.
• But if shutdown is called while the thread is already mid-export from a regular tick, the @condition.signal has nothing waiting on it. Once that in-flight export finishes, the thread just sees @continue == false and exits the loop directly, skipping any subsequent collect for metrics recorded during/after that export.
• shutdown itself only calls @exporter.force_flush if @exporter.respond_to?(:force_flush) (a flush of the exporter's own internal buffer, if any) followed by @exporter.shutdown. It never explicitly triggers the reader's own collect-and-export, so it's entirely dependent on winning the race above.

I would like to know if it's possible for the PeriodicMetricReader#shutdown to deterministically perform a final collect-and-export cycle (the same effect as force_flush) before the exporter is shut down, regardless of what the background thread happens to be doing at the moment shutdown is called e.g. by having shutdown explicitly call the reader's own force_flush (or equivalent) rather than relying on the thread's wait state.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

Start in metrics_sdk/lib/opentelemetry/sdk/metrics/export/periodic_metric_reader.rb, reading shutdown, force_flush, and the background export flow. Reproduce shutdown during an in-flight export and verify that metrics recorded since the last tick are collected and exported before the exporter is shut down, without relying on the thread's wait state.