git_repository treats failed git submodule update as success and caches an incomplete tree

### Description of the bug:

### Description

`git_repository` / `new_git_repository` with `init_submodules` or `recursive_init_submodules` can succeed even when `git submodule update` fails. The incomplete working tree is then cached as a valid repo (commit SHA matches, `.git` is deleted). Later builds never retry the clone and fail in surprising ways (missing submodule files).

This is a regression from older Bazel, which ran submodule update through `_git()` (fail-closed). Current code uses `_git_maybe_shallow()` and ignores its return value.

### Which category does this issue belong to?

_No response_

### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

```bash
ROOT=$(mktemp -d)
git -c init.defaultBranch=main init -q "$ROOT/p"
git -C "$ROOT/p" -c user.email=a@b.c -c user.name=r commit --allow-empty -qm e
git -C "$ROOT/p" update-index --add --cacheinfo 160000,$(git -C "$ROOT/p" rev-parse HEAD),vendor/sub
printf '%s\n' '[submodule "vendor/sub"]' ' path = vendor/sub' ' url = https://127.0.0.1:1/x.git' > "$ROOT/p/.gitmodules"
git -C "$ROOT/p" add .gitmodules
git -C "$ROOT/p" -c user.email=a@b.c -c user.name=r commit -qm s
C=$(git -C "$ROOT/p" rev-parse HEAD)

mkdir "$ROOT/ws"
cat > "$ROOT/ws/MODULE.bazel" <

Start by running the provided bazel fetch reproduction, then inspect the git_repository/new_git_repository entry points and the mentioned _git() and _git_maybe_shallow() helpers. Done means a failed git submodule update causes the repository fetch to fail and does not cache the incomplete tree as valid.

Written by the indexing model from the issue text.