Nested submodule repos inherit the host's core.autocrlf, failing 8 tests on Windows

[JerryHyun]

Eight tests/submodule.rs tests fail on Windows because the nested repository a submodule lives in inherits the host's core.autocrlf.

This only becomes visible once the Rust suite can run on Windows at all — see #98, which fixes that and closes the same problem for every other suite. The fix there sets core.autocrlf=false locally in each throwaway repo, which is enough everywhere except here.

Why the same fix does not reach these

git submodule add clones the child repository into the parent, creating an independent git repo. Config is not inherited, so the nested repo starts with none of TempRepo::apply_test_config's settings and falls back to the host's global — which on Windows is core.autocrlf=true by default.

And in most of these tests the clone happens inside the call under test, so there is no moment for the test to configure the nested repo before its working tree is written:

// tests/submodule.rs:909
let added = tauri::async_runtime::block_on(submodule_add(...));
assert_eq!(parent.read("sub/f.txt"), "hello\n");   // reads "hello\r\n"

Where

test	line
submodule_add_clones_new_submodule_and_it_is_immediately_clean	909
submodule_add_with_branch_checks_out_that_branch_not_the_default	959
submodule_deinit_with_force_backs_up_dirty_content_then_clears	1225
bug2_force_deinit_refuses_when_a_nested_submodule_of_a_submodule_is_dirty	1684
submodule_status_on_cyclic_nested_submodule_terminates_cleanly_instead_of_crashing	2006
submodule_update_recursive_handles_nested_submodule_of_a_submodule	743
submodule_update_with_init_clones_and_checks_out_never_initialized_submodule	—
submodule_update_without_recursive_leaves_the_nested_submodule_uninitialized	—

All fail the same way — a compared string differs only by \r:

assertion `left == right` failed
  left:  "hello\r\n"
  right: "hello\n"

Fix

Per-repo config cannot reach a repo the code under test creates, so this wants a process-wide answer instead: point the test binary's own GIT_CONFIG_GLOBAL at a fixture-owned file containing [core] autocrlf = false, so every git the tests or the code under test spawn inherits it — nested clones included.

tests/common/mod.rs's git() already uses GIT_CONFIG_GLOBAL=/dev/null per-invocation for exactly this class of isolation; the difference here is that it has to apply to the whole process, not just the fixture's own calls.

Worth deciding deliberately rather than reflexively: forcing autocrlf=false makes the suite green, but real Windows users run with it on. If any of these assertions is failing because the app mishandles a CRLF working tree rather than because the test compared the wrong bytes, that is a user-facing bug this would hide. The eight above all look like plain content comparisons, so this is probably safe — but it is the kind of thing worth one look before turning the knob.

Note

Two more tests/submodule.rs failures on Windows are not this cause and are filed separately.

---

_{Found while making cargo test runnable on Windows (#98). Counts measured with cargo test -j 2 --no-fail-fast on Windows 11 / MSVC 14.50; every failure above was read from the run output rather than inferred.}