scaffold-project.py: a partial-clone --pin-source lacking the pinned commit or its trees is fetched into over the network #1182

scaffold-project.py --pin-source reads the pin with the same declared_pin_values (scripts/shape_materialize.py) that adopt-project.py plan used before #1162's fix.

Measured. Lane 1 (w1145b) measured this through adopt-project.py plan on 2c8082a2, with git 2.43:

• a --filter=tree:0 clone ran the clone's upload-pack once and gained a promisor pack (.promisor 1 -> 2);
• a --filter=blob:none clone lacking the pinned commit did the same;
• a blob:none clone that holds the commit read nothing over the network.

Not measured. The scaffold itself; by reading, it fetches the same way. Its refusal's remedy names no cause where the clone holds the pinned commit but lacks its trees.

• Run the scaffold's pin read with GIT_NO_LAZY_FETCH=1, as adopt-project.py plan: a partial-clone --source is fetched into, as check and execute were before #1145 #1162 does for plan, and name a partial --pin-source in its refusal.
• Add rows for the two forms above, plus a control for a blob:none clone that holds the commit.

Outside v1.2.0 by Brett Heap's ruling of 2026-10-21T10:32:04Z ("leave the follow-ups out of v1.2.0").

Lane: openreposhape-1 (openRepoShape-1)