Make Git handling more efficient

[tomschr]

Situation

Currently, we have a "checkout cost": the situation with cloning and managing temporary Git repos is like this:

deliverable 1  →  temp dir 1  →  daps DC-file-1
deliverable 2  →  temp dir 2  →  daps DC-file-2   (same repo+branch as #1!)
deliverable 3  →  temp dir 3  →  daps DC-file-3   (same repo+branch as #1!)
…

• A single repo with a main branch (say 100 DC files) + 6 maintenance branches (say 30 DC files each) = 7 unique (repo, branch) pairs covering 280 deliverables.
• Translations live in subdirectories of the same branch → same (repo, branch) key → they all share one worktree with no extra cost.
• Legacy repos with translations in a separate branch get their own entry in the group map, which is correct.

So across our 700 deliverables you likely have on the order of 20–50 unique (repo, branch) pairs, meaning you're creating ~15–40× more worktrees than necessary today. At ~0.3s each that's several minutes of pure overhead, and more importantly those 770 worktree-add calls also contend on the bare repo's internal lock sequentially.

Use Case / User Story

As a user, I want to call docbuild without too much overhead.

Possible Implementation

The optimal approach would be to recognise that many deliverables share the same (repo, branch) pair, create one worktree per unique pair, and run all the daps invocations for that pair against the same checkout concurrently (since daps only reads — it takes a DC file path and an output path, it doesn't write into the worktree):

repo A / branch X  →  1 worktree  →  daps DC-file-1, daps DC-file-2, daps DC-file-3 …
repo A / branch Y  →  1 worktree  →  daps DC-file-4, daps DC-file-5 …
repo B / branch X  →  1 worktree  →  daps DC-file-6 …