fix(crew): a member takes a push from a shallow lead when it lacks the parent commit

[OowhitecatoO]

Short version first; the collapsed section below has the detail if it is useful.

Impact: crew update and crew add fail on the push leg for a member that lacks the parent of the lead's commit. The report says the build failed on <member>, although nothing was built.
When: The lead runs from a Herdr-managed install, whose checkout is shallow (ADR 0006), and the member has not fetched that parent from GitHub itself. A member that crew add installs from such a lead starts with a checkout whose tip names a missing parent, so git rev-list and git fsck fail there.
Cause: git bundle create - HEAD on a shallow checkout writes the tip without its parent, and a bundle cannot carry a shallow marker (git prints option "updateshallow" is ignored). The member's git fetch then refuses with did not send all necessary objects.
After this change: When that fetch fails, the leg unbundles the same objects without the connectivity check and checks out the lead's commit. If that commit names a parent the member does not have, the leg records the commit in .git/shallow, as git fetch --depth would. A member that has the parent fetches as before and keeps its full history. The member still needs no route to GitHub, and it still ends on exactly the lead's commit (ADR 0015 (b)).
Test: Three cases run the real leg under /bin/sh against a shallow lead: a member that lacks the parent, a member that holds it, and a fresh install. The first and the third fail without the change.

Details, if useful

Field case. The lead was a Herdr plugin install of 1.21.1. The member, whitecat-nbu, was a checkout at v1.21.0 with history up to that tag. The lead's commit c7ddd1e has parent 1fc045f, which the member did not have:

✗ push     the build failed there
error: the build failed on whitecat-nbu — 警告: 選項「updateshallow」被 /tmp/collie-add.vTLp3D/bundle 忽略

The line shown is the warning because the member's git prints its errors in Chinese, so errorLine finds no error: line. The same fetch with git in English ends with error: … did not send all necessary objects. After git fetch --tags origin on the member, which gave it the parent, the same crew update succeeded.

Verified over ssh. I took a real bundle from the lead's shallow v1.21.3 checkout and ran the changed leg on two throwaway members at v1.21.0 that lacked the parent: a Linux member with history up to v1.21.0, and a macOS member with a depth-1 checkout. Both exited 0, ended on the lead's commit with git fsck --connectivity-only clean, and built a binary that runs. A third member that held the parent took the fetch path, wrote no .git/shallow, and kept its 2615 commits.

What the boundary costs. A merge that arrives with one parent missing is cut as a whole, so the parent the member does hold drops out of view, though not off disk. And collie update on that member fetches with --depth 1 from then on, as it already does on a Herdr-managed checkout. The comment above the loop says both.

Out of scope. On those throwaway members the build was stamped 1.21.3-dev, because they carried other release tags but not v1.21.3. The unchanged fetch path stamps a member in that state the same way, so this change does not affect it. I also left the error wording alone: a failed fetch is reported as the build failed, and on a non-English git errorLine falls back to the first stderr line.

The full backend suite passes on Bun 1.4.1 (8542 pass), as do the web suite and both typechecks.

[OowhitecatoO]

The Windows job failed on the skip budget, not on a test: the three new cases skip there, so cli had 17 skips against 14. They run the install leg, POSIX sh that a crew member runs over ssh, and a Windows machine cannot be a crew member (WINDOWS_CREW_SENTENCE), the same reason scripts/install.test.ts is budgeted. c577bab raises the cli budget to 17 and names the three in windows-suites.ps1.