unnecessary (?) installation failure when git lfs detects "short" files

current in-dev MESA version at time of posting: mesa/data/version_number = acd763a
remote installation on OzSTAR HPC cluster

since I don't have root access here, I manually installed git lfs using these instructions: https://github.com/git-lfs/git-lfs/issues/4134

this got me past the "git lfs not installed" issue successfully, but I kept encountering versions of
"Some data files were not successfully retrieved" no matter how many times I pulled. I finally went into the install script and commented out `exit 1` in the block:

``` # check that each LFS file has a full copy on disk
FILE_LIST=$(git-lfs ls-files | awk '{print $NF}')
for LFS_FILE in ${FILE_LIST}; do
# the checks have this form to handle uncommitted changes to LFS files
# if no file exists, that means the file was probably deleted and that's OK
# if the file exists, but is short, then it is probably the bare LFS pointer
# and that indicates a problem retrieving the file
if [ -f "${LFS_FILE}" ] && [ $(du -k "${LFS_FILE}" | cut -f1) -le 4 ];
then
echo
echo "${LFS_FILE} is smaller than expected for a file tracked by git LFS"
echo
echo "****************************************************************"
echo "* Some data files were not successfully retrieved *"
echo "* *"
echo "* Try running: *"
echo "* git lfs install --force *"
echo "* and then *"
echo "* git lfs pull *"
echo "* *"
echo "****************************************************************"
echo
#exit 1
fi
done
```

when I ran `./install` after this, I got a warning (but no exit) for seemingly every large file, but then the MESA installation proceeded as normal and concluded successfully.

To me, it seems like the above code block assumes that detection of "short" large files will automatically result in a botched install, but then it doesn't (necessarily). In which case, we're causing installation failures that we don't need to. Can the install script be modified in some way to avoid this? Perhaps replacing the forced exit with a warning?

Start with the ./install script and the shown git-lfs ls-files and short-file check, then reproduce the installation on an environment where LFS files are reported as short. Determine whether the check should warn or stop, and verify that the chosen behavior still detects genuinely missing data while allowing a successful installation when appropriate.

Written by the indexing model from the issue text.