fix(elasticsearch): treat HTTP 401 as healthy in the migration marker check

curl -f treated any 4xx as failure, including 401. Users who enable
xpack.security (a supported override via ES_SETTING_XPACK_SECURITY_ENABLED)
got 401 on the unauthenticated healthcheck request, so the version marker
was never written and every restart re-logged the one-time migration
notice. Read the HTTP status directly and accept 200 or 401.

Reviewed and skipped: the cp -rn merge-into-existing-directory concern —
verified empirically (both locally and against the image's Debian/GNU
coreutils base) that GNU cp merges correctly into a pre-existing
same-named destination without nesting; the existing test suite already
exercises this exact path (legacy 7.x data preserved during migration).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

elasticsearch/rootfs/usr/local/bin/addon-init.sh

@@ -127,7 +127,11 @@ echo "Data location: $PERSISTENT_HOME (persistent). Please wait while elasticsea
 if [ "$data_version" != "$current_version" ]; then
     (
         for _ in $(seq 1 180); do
-            if curl -A "HealthCheck: Docker/1.0" -s -f "http://127.0.0.1:9200" >/dev/null 2>&1; then
+            # Check the HTTP status directly instead of curl -f: a 401 means
+            # Elasticsearch is up and answering (security just requires
+            # auth), so it must count as healthy too, not as a failure.
+            status=$(curl -A "HealthCheck: Docker/1.0" -s -o /dev/null -w '%{http_code}' "http://127.0.0.1:9200" 2>/dev/null || true)
+            if [ "$status" = "200" ] || [ "$status" = "401" ]; then
                 echo "$current_version" >"$VERSION_MARKER"
                 echo "Elasticsearch $current_version started successfully; data version recorded."
                 exit 0