Feature Request: Support shallow clone (--depth) for repo add and repo checkout

[cncqcl]

Problem

multica repo checkout and multica repo add always do a full git clone --bare clone cache, with no way to specify a shallow clone (--depth 1).

For repos with large binary assets in version history (e.g., SQLite databases, research artifacts), the git pack can grow to over 1 GB even though the working tree is ~700 MB. A shallow clone would cut the download significantly.

Example use case: The ADR research knowledge base repo has resources/kb.sqlite (~50 MB per commit) plus 600 MB of capsule files. Full git pack is ~1.15 GB. With --depth 1, the download would drop to ~700-800 MB — a ~35% reduction on first clone.

Proposed solution

Add an optional --depth <N> flag to both multica repo add and multica repo checkout:

# Shallow clone on first add
multica repo add https://github.com/example/repo.git --depth 1

# Override depth at checkout time
multica repo checkout https://github.com/example/repo.git --depth 1

This would pass through to git clone --bare --depth <N> (for the daemon's bare cache) and git worktree add (for checkout).

For repos already in the workspace registry that were originally full-cloned, multica repo checkout --depth 1 could either:

• Re-clone the bare cache with --depth 1, or
• Warn that the existing cache is a full clone and proceed with the full clone.

Alternatives considered

1. Manual git clone --depth 1 — works but bypasses Multica's repo registry and bare clone cache, so no reuse across runs and agents.
2. Git LFS — would help but requires the repo owner to set up LFS tracking; --depth is a simpler client-side fix.
3. Sparse checkout — complementary but doesn't reduce git object download.

Related size data

For context on a real-world case:

Component	Full clone	--depth 1 (est.)
Git pack	1.15 GB	~200 MB
Working tree	~700 MB	~700 MB
Total download	~1.85 GB	~900 MB