[Jinwoo-H]

	Files	Added	Deleted	Net
Test	0	0	0	0
Prod	788	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​788	$\color{#cf222e}{\Huge{\mathbf{−}}}$​788	0

#22376 re-recorded the bundle-fetch goldens with baseline pinned to its own branch commit, which the squash left unreachable from main, so the recording pin guard's ancestry check is red on main until this lands. This repins the corpus to main's tip 0c2514e, the tree its fenced paths match. Every golden changes only its baseline line (788 files, two distinct changed lines after masking the sha); the recorder's own reproduce check passes from the pinned tree. Same shape as #22185 after #22179.

[pullfrog]

✅ No new issues found.

Reviewed changes

• Repin of the RPC recording corpus — every golden under mobile/rpc-foundation/goldens/ and mobile/rpc-foundation/pilot-scenarios.json moves its baseline header from 97b13ec7… to 0c2514e7e0…, main's tip and the #22376 squash commit. This is the documented follow-up for a pin a squash left unreachable from main (mobile/src/test-support/rpc-recording/README.md, "Recording a behaviour change"; same two-step as #20563/#20895 and #22185/#22179).

Verified mechanically: the 788 changed files hold exactly 788 added and 788 removed lines, and the only two distinct line contents after masking the sha are the old and new baseline values — no golden's body, digest, or scenario moved. All 787 goldens plus the manifest carry the new sha, and none retains the old one.

The new pin is correct in both directions the guard checks: 0c2514e7e0 is main's tip (the exact tree the corpus was recorded from), so the ancestry check passes now and stays an ancestor after merge; and the reproduce check, which will run because the corpus provenance moved, checks out that same tree and compares the candidate goldens, with the runner refusing any golden whose baseline disagrees with the manifest — so the repin is validated end to end.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}