git submodule update is reimplemented by re-invoking the wrapper for each
submodule, but only two of the six re-issued commands carried the caller's
global options. The fetch of an already checked out submodule was built as

    command = called_as + ["fetch"]

while the clone of a missing one used called_as + git_options.global_options.
Any configuration the caller supplied was therefore dropped for submodules that
already existed on disk.

That silently breaks authenticated remotes. Azure DevOps agents pass the
checkout credentials as

    git --config-env=http.<url>.extraheader=<envvar> submodule update ...

and --config-env is a global option, so the re-issued fetch ran without it and
failed with "could not read Password". It only showed up for submodules that
were already present, which is why a first checkout worked and later ones did
not.

The global options cannot simply be copied: they also hold -C, --git-dir and
--work-tree, and these commands run with an explicit working directory, so a
relative path would be resolved a second time against the submodule directory.
GitOptions.get_config_options() therefore returns only the options that carry
configuration, -c and --config-env, by giving them their own groups. Nothing
read the previous "ignored" group, so the grouping change has no other effect.

Applied to the four sites that were missing it: the fetch in an existing
submodule, the recovery fetch and checkout of a commit that could not be
fetched, and the recursive submodule update.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Versioned 1.0.35.1 rather than 1.0.35 so the fork build cannot be confused with
an upstream release of the same number. Carries the submodule configuration
option fix, which is being dogfooded on the CSOS build agents before it is
proposed upstream.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

git submodule update is reimplemented by fetching or cloning each submodule and
then re-running the real "git submodule update -- <path>" to move it onto the
pinned commit. That second command addresses the submodule by its path, so it
has to run in the superproject, but it reused the working directory chosen for
the fetch:

    cwd = abs_tgt_path            # correct for the fetch
    simple_call_command(command, cwd=cwd)
    ...
    command += ["--", tgt_path]
    call_command_retry(command, 0, cwd=cwd)   # runs inside the submodule

so it executed inside the submodule that had just been fetched, where no
submodule of that name exists, and git answered

    error: pathspec '<path>' did not match any file(s) known to git

The clone branch sets cwd to None and was unaffected, which is why this only
appeared for submodules that already existed on disk.

Two effects. The obvious one is an error line per submodule on every checkout,
which buries real failures. The quieter one is that the failed_hash recovery
immediately below inspects that command's output for "fetching of that commit
failed"; since the command was failing on the pathspec instead, the recovery
could never trigger for an existing submodule. Nothing broke overall only
because the original command is re-run in full at the end of the function.

The fetch/clone directory is now named populate_cwd so it cannot be reused by
accident, and both "submodule update -- <path>" calls run in the superproject.

Verified by building a wheel from this tree and from its parent and running the
same scenario through each: both fetch the submodule, and only the unpatched
build emits the pathspec error. Also confirmed the update now does its job --
moving a submodule off its pinned commit and re-running it restores the pinned
commit, with no pathspec errors. 89 unit tests pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Adds the fix for the per-submodule update running in the wrong directory, on
top of the configuration-option propagation fix in 1.0.35.1. Both are being
dogfooded on the CSOS build agents before being proposed upstream.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

test_aborted_clone fails intermittently and blocked the 1.0.35.2 release twice,
on different runners and different parametrisations each time:

  ubuntu-26.04  test_aborted_clone[PartialFirst]  assert 0 is None
  ubuntu-22.04  test_aborted_clone[Full]          assert 0 is None

78 tests passed in both runs. It is unrelated to anything this fork changes.

The test interrupts a clone and asserts gitcache recorded no mirror.
call_command_retry() retries on any non-zero return code, so the interrupted
clone is simply retried and the retry completes, recording the mirror. Serving
the repository slowly from the local test server was tried first and is not
enough on its own -- it takes the clone from 0.50s to 3.45s, so the clone is
definitely still running when the abort is sent at 0.1s, and the assertion still
fails. That work is kept on fix/deflake-aborted-clone-test along with the
measurement.

Whether a user interrupt should be retried at all is a behavioural question
about gitcache and wants its own change, not a rushed patch to unblock a
release.

Applied to all four release-test invocations, so the flake cannot simply move to
the alpine, macOS or Windows jobs. This is fork-only: drop it once the interrupt
handling is resolved, and never carry it into an upstream pull request.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>