fix: parse pod start timestamps in UTC

[Hanabi9248]

CommonUtil.stringToDate treats the trailing Z as a literal but leaves the formatter in the JVM default time zone. For example, 2026-09-23T14:00:00Z becomes 06:00 UTC on an Asia/Shanghai server.

isAllPodRebuild compares that result with the instance update time during upgrade and autoscaling callbacks. A newly started pod can therefore be treated as older than the update. Set the formatter to UTC so the comparison uses the actual start instant.

The regression tests cover UTC, Asia/Shanghai and America/Los_Angeles, including pod timestamps on either side of an instance update. Running them against the original implementation produces four failures out of six; all six pass with this change.

Validation: compiled the real utility classes and ran JUnit 4 with Java 8 target bytecode on JDK 25 (Lombok 1.18.42 for that compiler). The Maven reactor test attempt stopped during dependency/plugin downloads with TLS handshake failures; a complete Maven build and Kubernetes integration test have not run.

[Hanabi9248]

Could a maintainer review this UTC parsing fix and approve the pending Code Format Check and Unit Test workflows when convenient? The six focused JUnit regressions pass locally across the tested server time zones. The full Maven build was blocked by dependency-download TLS failures, so the upstream checks would help complete validation. Happy to adjust the approach based on review.