native HTTP clone --depth N never writes .git/shallow

[mizchi]

Summary

Over the native smart-HTTP transport, bit clone --depth N fetches the right number of commits but never records a shallow boundary. The resulting repository is shallow in content while reporting itself as complete, which breaks fetch --unshallow and fetch --depth afterwards.

The local/process transport does write the file (though with the wrong contents — filed separately).

Repro

Serve a bare repo with git http-backend and clone it. bit must run with --no-git-fallback, otherwise clone is delegated to real git.

tool  transport  depth  .git/shallow  is-shallow-repository  log
git   file       2      yes           true                   2
git   http       2      yes           true                   2
bit   file       2      yes           true                   2
bit   http       2      NO            false                  2

Knock-on effects over HTTP:

after a --depth 2 clone	git	bit
fetch --unshallow then rev-list --count HEAD	6	3
fetch --depth 4 then rev-list --count HEAD	4	3

fetch --unshallow is a no-op because remote.mbt gates the deepening request on the shallow file existing:

let updates_shallow_state = depth > 0 || (unshallow && fs.is_file(shallow_path))

With no .git/shallow, the fetch short-circuits as already up to date and the clone can never be completed.

Cause

modules/bit_protocol/src/upload_pack_http_common.mbt

• prepare_clone_with_http (around line 279) calls fetch_pack_with_http, the variant that returns only the pack and throws the shallow / unshallow lines away. fetch_pack_with_http_result returns them.
• clone_to_fs_with_http (line 294) and its async twin never call @repo.apply_shallow_updates.

#183 fixed the same gap on the JS clone/fetch path; the native HTTP path still has it.

Expected

An HTTP --depth clone records the server's shallow boundary exactly as the local transport does, so rev-parse --is-shallow-repository is true and later deepening works.