fix(audit): materialize recorded git submodules before client builds

[ORESoftware]

Summary

Fix a shared fleet-audit false-negative at the checkout layer instead of patching downstream clients.

The August 12 fleet run (31580641419) cloned client repositories without initializing recorded git submodules. For opto-sync/opto-sync-clients, that made the audited checkout structurally incomplete: Rust and Dart paths under the recorded syncer.c gitlink were absent, and the Zed package smoke test could not find syncer.c/core/include/syncer.h.

Dependency path

zed-pkg/.github nightly fleet runner -> opto-sync/opto-sync-clients -> syncer.c gitlink -> Rust/Dart bindings

The client repository records the dependency at a gitlink SHA; the runner was leaving that exact dependency unmaterialized.

Fix

• clone each audited target with --recurse-submodules;
• keep the existing exact default-branch checkout and full branch visibility;
• add a unit contract proving the clone command materializes recorded gitlinks;
• make clone-failure evidence explicitly include submodule checkout failure.

This does not change application code, dependency versions, credentials, or any non-audit runtime.

Validation

Static unit coverage is added in tools/test_run_clients_batch.py. The repository CI/fleet canary should exercise the actual authenticated recursive checkout before this is promoted.

This is intentionally draft until exact-head CI is green and a focused fleet rerun proves the Opto Sync Rust/Dart paths no longer fail because the gitlink is empty.

[ORESoftware]

Validation update: both existing exact-head PR checks are green on fdee2932d020df11b281a5c4bb3c96e9e3f37cb1 (baseline policy run 31682801107 and public-privacy-boundary run 31682801106). The baseline job validates organization policy; it is not a substitute for the focused Rust/TypeScript/Dart fleet canary, so this PR remains draft until a recursive-checkout fleet run exercises the Opto Sync graph.

[linear-code]

DEN-3740