fix: log uncaught exceptions from CliRunner main so JobManager pod logs capture them

[velo]

Problem

When the SQL job submitted via CliRunner fails at planning/submission time (e.g. an invalid EXECUTE STATEMENT SET BEGIN ... END), the JobManager pod restarts in a loop with no errors or warnings on kubectl logs. The only place the actual exception is visible is via kubectl describe pod, surfaced as a Kubernetes Event by the Flink Kubernetes Operator (which polls the Flink REST API).

This makes log scrapers (Fluent Bit, Loki, Datadog, etc.) completely blind to the failure — they only see the looping JM with no stack trace.

Fix

Wrap CliRunner.main() in a try { ... } catch (Throwable t) that calls log.error("flink-sql-runner failed", t) and rethrows. The rethrow preserves Flink's existing exception reporting through PackagedProgram (so the operator's REST-based status path still works), while the explicit log.error puts the full stack trace on stdout where log scrapers can pick it up.

Why not System.exit(1) + LogManager.shutdown()?

In mode: standalone the JobManager JVM keeps running after main() returns/throws — Flink reports the failure via REST and the operator tears the pod down later. Forcing System.exit would kill the JM hard and bypass the REST exception path. log4j2's default Console appender uses immediateFlush=true, so the log.error line is on stdout before the throw executes — no explicit flush needed.

Test plan

• CI builds and existing tests pass
• Deploy to a test cluster and trigger a deliberately broken SQL plan; verify the stack trace now appears in kubectl logs of the JobManager pod, not just kubectl describe pod