fix(xnat): Properties file customizations no longer silently ignored for XNAT 1.10+

[johnflavin]

When running the chart against an XNAT 1.10 image and writing contents to xnat-conf.properties, xnat started correctly but failed to pick up my properties. The cause was the non-root init container failing to write the properties file to the image's root-owned ${XNAT_HOME} due to a permissions error, but still exiting 0.

Two changes in this diff:

• The init container now copies ${XNAT_HOME} to the /XNAT_HOME volume at the start, rather than at the end. This way we never write anything to the root-owned ${XNAT_HOME}.
• The init script runs with the bash -e flag, so errors in writing or copying the files will fail init. Without this it was harder to track down the source of the issue, because the init container's script seemed to be operating correctly.
  • A minor change as a consequence of this: we have to change the line [ -d /TOMCAT ] && ... into an explicit if [ -d /TOMCAT ]; then ..., because the former would cause a spurious script failure under -e where the latter correctly just moves on.

[andrey-embarklabs]

Nice fix, and the diagnosis is exactly right: the old flow wrote the properties into the root-owned ${XNAT_HOME}/config and only copied to the volume at the end, so on a non-root image those writes failed and, without -e, the script continued and the final copy carried the pristine config. Copying ${XNAT_HOME}/!(plugins) to the volume first and pointing every write at /XNAT_HOME/config fixes the actual cause rather than the symptom.

A few things I checked that all hold up:

• The [ -d /TOMCAT ] && cp to if ... then ... fi conversion is necessary under -e: a top-level A && B list with a false A returns non-zero and aborts, whereas the if returns 0. And leaving the trailing-newline line as [ ... ] || echo is correct, since an A || B list is exempt from -e and returns 0 in both branches.
• mkdir -p /XNAT_HOME/config correctly covers the case where the config dir isn't present after the copy.
• Password handling is preserved: the { set +x; } window still wraps XNAT_DB_PASSWORD, -e stays active so the empty-password guard still fires, and nothing new reaches the trace.
• Rendered both the externalSecret and default paths; both are valid. xnat-home is an emptyDir, so there's no persistence/idempotency interaction from moving the copy earlier.

One small request: the diff drops the rationale comment above securityContext (the "Same securityContext as the main container..." note explaining why pinning a uid just takes the non-root branch). That's unrelated to the reorder and still accurate, so I'd keep it.

Two optional notes, neither blocking:

• With copy-first plus --preserve=mode plus -e, if the base image ever shipped a read-only default xnat-conf.properties under $XNAT_HOME/config, the later cp /tmp/... overwrite would fail as non-root and now abort.
• XNAT images don't ship that file, so it's unreachable today; just flagging the one new interaction -e introduces.

Since you're hardening failure behavior anyway, set -u would catch an unset ${XNAT_HOME} (an empty value would make the copy read from /). Out of scope for this fix, take it or leave it.

LGTM either way.