Fix server image signal delivery by exec'ing the JVM

[sergio-u-simspace]

Summary

This change updates the server Docker startup path so the JVM becomes the main container process and receives termination signals directly during container shutdown.

Today the image starts the JVM from a shell script and wraps it in a tee pipeline. In that process layout, the shell is the long-lived parent process and the JVM does not receive the container termination signal directly from the normal container stop path.

This change replaces the shell-wrapped JVM startup with exec java ..., so the shell is replaced by the JVM and the JVM becomes PID 1.

Process layout

Example process layout before the change:

PID	Process
1	/bin/sh /app/startup.sh
7	nginx: master process
18	java -jar conductor-server.jar
19	tee -a /app/logs/server.log

Example process layout after the change:

PID	Process
1	java -jar conductor-server.jar
8	nginx: master process

During normal container termination, the runtime signals PID 1. Before this change that was the shell; after this change it is the JVM.

Why this matters

With this change, JVM shutdown hooks and framework-level graceful shutdown mechanisms can run when the container is terminated.

To use that behavior in a Spring Boot deployment, configure server.shutdown=graceful and a suitable spring.lifecycle.timeout-per-shutdown-phase value.

To test it:

1. Start the container
2. Confirm the JVM is the main process
3. Send SIGTERM or terminate the pod/container
4. Verify the application logs its graceful shutdown sequence before exit

Additional note

As part of the same change, the startup script no longer wraps the JVM in tee. This keeps the JVM out of a shell pipeline and also avoids unbounded growth of /app/logs/server.log, while preserving container stdout/stderr logging.

[c4lm]

I am not sure we want to lose that file, I think we need a spring logging config with conductor.server.logfile property (if it's application-level then we don't need that tee anymore)