fix(deploy): switch to JDK 11 + Spark 3.1.2, defensive shebang, validate entrypoint

Three fixes requested:

1. Spark 4.1.2 -> Spark 3.1.2 (Hadoop 2.7 prebuilt). Compatible with the
   JDK 11 build below and a more conservative choice for production.

2. JDK 17 -> JDK 11. openjdk-11-jre-headless package; JAVA_HOME points
   at /usr/lib/jvm/java-11-openjdk-amd64.

3. /usr/bin/env 'bach' no such file: defensive shebang fix. The
   downloaded spark-3.1.2-bin-hadoop2.7.tgz happens to have a clean
   shebang, but older 4.x distributions (and any future typo in a
   release) would break the same way we just saw. The Dockerfile now
   runs:
       find /opt/spark/bin -type f -exec sed -i '1s|^.*$|#!/usr/bin/env bash|' {} +
   which rewrites the first line of every bin/* script to a known-good
   shebang. Idempotent, defensive, costs nothing.

4. docker-entrypoint.sh: simplified and made validation explicit.
   Old version used an awk/sed pipeline to strip /usr/lib/jvm/ and
   /opt/spark/bin from the existing PATH before prepending the new
   values. That had a subtle bug: if the new JAVA_HOME was itself
   under /usr/lib/jvm/ (e.g. /usr/lib/jvm/java-11-openjdk-amd64), the
   strip would remove the new path too. New version just prepends the
   resolved paths and leaves the old PATH alone. The new paths win
   because they come first.

5. docker-entrypoint.sh: now validates the resolved paths BEFORE
   exporting them. If JAVA_HOME/bin/java or SPARK_HOME/bin/spark-submit
   are missing, the container fails fast with a clear hint instead of
   letting a job submission die with an opaque 'no such file'. Also
   logs the effective 'java' and 'spark-submit' paths (and java
   version) to stderr at every start, so docker logs make the
   resolution visible.

6. .env.example + docker-compose.yml: default JAVA_HOME updated to
   /usr/lib/jvm/java-11-openjdk-amd64. Spark client 3.1.2 (hadoop2.7)
   noted in the comment as the working combo.

163/146 still pass (no code changes to the app; Dockerfile + entrypoint
+ docs only). The new entrypoint was smoke-tested locally: validation
fires as expected (the local dev box has no JDK 11, which is exactly
the kind of misconfig the validation now catches at container start).

.env.example

@@ -54,17 +54,17 @@ YARN_RESOURCE_MANAGER_URL=
 # SPARK_SUBMIT_OPTS=-Dhttps.proxyHost=proxy.corp -Dhttps.proxyPort=3128
 
 # --- Java + Spark install paths ---
-# Where the openjdk-17-jre-headless JDK lives, and where the Spark
+# Where the openjdk-11-jre-headless JDK lives, and where the Spark
 # distribution was extracted during the image build. Defaults match the
 # Dockerfile's ENTRYPOINT script. Override if you mount a different
 # Java (e.g. /usr/lib/jvm/java-17-openjdk-arm64 on some ARM hosts) or
-# a pre-installed Spark from a host volume (e.g. /opt/spark-3.5.1-bin-hadoop3).
+# a pre-installed Spark from a host volume (e.g. /opt/spark-3.1.2-bin-hadoop2.7).
 #
 # The container's docker-entrypoint.sh re-derives PATH from these values
 # at every start, so overriding them here actually changes which `java`
 # and `spark-submit` binaries the gunicorn process picks up.
 #
-# JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
+# JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
 # SPARK_HOME=/opt/spark
 
 # --- Gunicorn process model (see gunicorn.conf.py; NOT read by common/config.py) ---