fix: Ensure container runnable in deployment

[matthewfeickert]

The container was getting stuck on startup on the AF (feickert-notebook-1 was this project and feickert-notebook-2 was one of the ML containers that was already supported, but started up right away)

This PR ensures that the CMD script is executable and then combines lines as shell manipulaitons are not persistent between RUN commands.

Additionally it also sets the base image to sslhep/analysis-dask-base:24.2.26 instead of the main tag for stability and then ensures that the environment will be automatically setup correctly in the event that "$@" is not a new shell like /bin/bash.

Examples:

• Get to Jupyter Lab environment after a new shell is created

$ make
$ docker run --rm -ti --publish 9999:9999 sslhep/analysis-dask-uc:24.2.26-debug /bin/bash
[bash][root]:analysis > . /release_setup.sh 
Configured GCC from: /opt/lcg/gcc/11.2.0-8a51a/x86_64-centos7/bin/gcc
Configured AnalysisBase from: /usr/AnalysisBase/24.2.26/InstallArea/x86_64-centos7-gcc11-opt
(venv) [bash][root AnalysisBase-24.2.26]:analysis > jupyter lab --no-browser --allow-root  # --allow-root needed as user is root

• Get to Jupyter Lab environment from passing in command to /.run (I assume that something like this is done by the pod?)

$ make
$ docker run --rm -ti --publish 9999:9999 sslhep/analysis-dask-uc:24.2.26-debug /.run jupyter lab --no-browser --allow-root  # --allow-root needed as user is root

[matthewfeickert]

I'm going to merge this (I assume that new builds get pulled in by the k8 cluster) and we can give this a go. If things don't improve we can revert this as needed.