refactor(scheduler): clean JVM shutdown for batch-style entry point

[mkuchenbecker]

Summary

Follow-up to PR #534 addressing reviewer feedback on the scheduler entry point.

The SchedulerApplication already used CommandLineRunner, but SpringApplication.run(...) left the context open after the runner finished — JPA pool / Spring framework threads (non-daemon) can keep the JVM alive, and the exit code does not reflect batch outcome. For a k8s cron-job-style batch app, that is the wrong shape.

Wraps SpringApplication.run in SpringApplication.exit + System.exit so the context is closed (@PreDestroy, JPA pool drain, etc.) and the JVM exits with a deterministic exit code after the CommandLineRunner completes. This is the standard Spring Boot batch-style entry point.

public static void main(String[] args) {
  System.exit(SpringApplication.exit(SpringApplication.run(SchedulerApplication.class, args)));
}

Scope

Only SchedulerApplication. AnalyzerApplication has the same shape and will be updated separately to keep this PR minimal and focused on the scheduler review thread.

Changes

• Client-facing API Changes
• Internal API Changes
• Bug Fixes
• New Features
• Performance Improvements
• Code Style
• Refactoring
• Documentation
• Tests

Testing Done

• ./gradlew :apps:optimizer:schedulerapp:build passes (compile + checkstyle + spotbugs).
• Added new tests for the changes made.
• Updated existing tests to reflect the changes made.
• No tests added or updated. The change is a one-line wrapper around the standard Spring Boot startup; behavior under unit test (where the app is not booted) is unchanged.

Additional Information

• Breaking Changes
• Deprecations
• Large PR broken into smaller PRs, and PR plan linked in the description.