Fix per-timeseries async cumulative start-timestamp distinction

Spec requirement

[Development] For cumulative async instruments, start timestamp SHOULD be instrument-creation time (if first series in first collection) or the prior collection's timestamp otherwise (sdk.md:853-876, Start timestamps).

Current behavior

Async streams reuse the same ||= start_time-on-first-write pattern as sync (via the shared aggregation classes, e.g. sum.rb:45 (permalink)) rather than distinguishing "first series in first collection" (instrument-creation time) from "first occurrence in a later collection" (prior collection's timestamp) — a simplification of the spec's two-case rule.

Suggested fix

Thread the instrument-creation timestamp through to async metric streams so the first-ever collection can use it, while later collections that see a first-time attribute set still use the prior collection's timestamp as today.

Related rows in SPEC_COMPLIANCE_METRICS.md

SDK-28

Start with the shared aggregation classes, especially metrics_sdk/lib/opentelemetry/sdk/metrics/aggregation/sum.rb around line 45, and compare the behavior with the SDK start-timestamps section linked in the issue. Trace how async metric streams receive collection timestamps and instrument creation time. Done means the first series in the first collection uses instrument-creation time, while a first-time attribute set in later collections uses the prior collection timestamp, with SDK-28 compliance updated as needed.