SUBS-041: cap submodule nesting depth with a SIMPLE counter at checkout — bail when the get-side sub-mount recursion goes too deep

Submodule checkout recursion (be get mounting a gitlink, then recursing into the mounted sub's own gitlinks) has no depth limit, so a deep / cyclic gitlink chain fans out until it crashes. The fix is DELIBERATELY TRIVIAL: thread ONE depth counter through the checkout sub-mount recursion and stop once it passes a small constant cap. No shared module, no ancestry/visited set, no changes to read views (status/diff/log/patch) — just the checkout. A prior over-engineered attempt (a subguard.js module threaded through 8 files) was DISCARDED as bullshit. Scope: be/verbs/get/get.js ONLY. See DIS-058, GET-039; method Issues.

Input

Context

be/verbs/get/get.js recurseSubMounts descends a mounted sub's gitlinks with NO depth bound; a deep or cyclic 160000 chain recurses until OOM/crash.
A TRUE content-addressed cycle isn't constructible (a commit sha depends on its content), so the real, buildable pathology is just a deep alternating pin-chain — a plain depth cap fully bounds it. That is sufficient (user ruling).
The be self-locator is NOT in scope — GET-039 makes it a symlink, not a sub. Add NO be-name special-case.

Goals

A small constant cap (e.g. MAX_SUBMODULE_DEPTH = 8) bounds the checkout sub-mount recursion: past it, stop descending — log a friendly skip, leave the mount point as-is, exit clean, no crash.
Legitimate nested mounts WITHIN the cap still mount and recurse (no regression to be-js-sub-cycle).

Constraints

be/ JS only, NO C. Touch ONLY be/verbs/get/get.js (the checkout sub-mount recursion). Do NOT add a new module; do NOT touch submount.js, core/recurse.js, classify.js, or any read view (status/diff/log/patch). KEEP IT MINIMAL — this is a few lines, one counter, one constant.
Repro-first (CLAUDE §17): ONE test — a chain deeper than the cap be gets bounded (anchors ≈ cap, not the chain length), no crash. Do not edit existing tests except to add that one case; do not regress be-js-sub-cycle.
MAY edit the MAIN tree (user ruling): /home/gritzko/journal/be.

WIP

Design decisions

Add a depth argument to the get-side sub-mount recursion (default 0 at the top-level mount); increment on each descent; when depth >= MAX_SUBMODULE_DEPTH, log + return WITHOUT mounting/recursing the deeper sub.
One module, one constant, one guard line. Nothing shared, nothing in the read path.

TODOs

Add the depth counter + cap — landed 6388c34e ("add submodule nesting limit", 30Jun): MAX_SUBMODULE_DEPTH = 8 (get.js:53), recurseSubMounts(g, rel, m, out, depth) bails past the cap with a friendly warn (get.js:854-881); top-level mount seeds depth 0.
RED/GREEN repro still missing (verified 2026-07-07: no be/test/ case greps depth cap/MAX_SUBMODULE): ONE case — a chain deeper than 8 jab gets bounded (anchors ≈ cap), exits clean; sub/cycle (within cap) intact.

Blockers and bummers

Touches be/verbs/get/get.js, which GET-039 also edits — small 3-way at land time; keep the change to a few lines to minimise it.

Outcome

Re-scoped 2026-06-29 to a SIMPLE checkout depth cap after the first attempt over-engineered it (a subguard.js module threaded through 8 files) and was discarded. The be corner case is GET-039's symlink-as-blob (landed; sub/selfloop guards it).
PARTIAL (audit 2026-07-07): the cap itself landed 6388c34e (get.js only, exactly as re-scoped); the deep-chain repro test is the only remainder.