Clone a task's submodules from the repo's own checkout

[tildesrc]

Spawn-prep filled a per-task clone's submodules by fetching each one from its forge-resolved URL — paid by every task on the repo. For a repo with a large submodule that dominates spawn-prep, while the superproject itself is nearly free (clone --local hardlinks the cache clone's objects).

When the repo's git_url names a checkout on this host, that checkout already holds every submodule's objects, so spawn-prep now clones them from it: a local clone with a hardlinked object store and no network.

The donor is matched by path, never by URL — the donor resolved its relative .gitmodules URLs against its own origin while the per-task clone resolves them against git_url, so the same submodule can legitimately carry two different URLs. Per superproject level:

1. submodule init — git resolves the declared URLs into config;
2. for each submodule the donor has checked out, overwrite that resolved URL with the donor's path (one the donor lacks keeps its own URL and is simply fetched);
3. submodule update for this level only — a nested submodule's URL can't be resolved, let alone redirected, before its parent exists;
4. recurse into each submodule against the matching donor level.

Then, once at the top, submodule sync --recursive restores the canonical URLs — in the config and in each submodule's own origin — so no donor path reaches the container.

It is only an optimisation, never a precondition: no local checkout, a raise, or any submodule still uninitialized afterwards all fall back to the plain submodule update --init --recursive, which is exactly what a repo without a donor gets. Repos whose git_url is a hosted forge are unchanged; giving them a donor by making the cache clone submodule-aware stays backlogged.

ADR 0011 gains §1c for the mechanism and its fallback rule.

Plan: the task's plan.md artifact.