tulipcc-pin: fold the refreshed refdocs/amy snapshot into the bump commit

[bwhitman]

Problem

Every auto-opened tulipcc pin PR starts red on tulipcc's refdocs-fresh check (e.g. shorepine/tulipcc#1215): moving the amy gitlink stales tulip/server/refdocs/amy/_VENDORED_FROM.txt — it stamps the source SHA — and this workflow never regenerated the snapshot, so a human had to push a fix-up commit to every pin PR.

Fix

New step between gather and pin:

• Clones shorepine/tulipcc@main (trusted; still never checks out or executes this repo's PR code — the pull_request_target safety note in the header holds) and runs its tulip/server/sync_amy_docs.py --sha <merged-sha>. With no submodule in the shallow clone, the script sources doc content from GitHub raw at that SHA.
• Emits the changed snapshot files as a git diff --cached --name-status list; the Git Data API step now includes them in the bump commit's tree as inline blobs (or sha: null deletions) alongside the gitlink.
• Best-effort: any failure (e.g. tulipcc@main's script predating --sha) leaves the list empty and the pin PR opens exactly as today — merge order between this and the companion tulipcc PR doesn't matter.

Companion tulipcc PR (adds the --sha flag): shorepine/tulipcc#1216

Testing

• YAML validates; simulated the new step locally against a fresh shallow tulipcc clone: script exits 0 sourcing from GitHub raw, and the name-status output is the exact tab-separated format the tree-builder parses.
• End-to-end validation happens on the next real amy merge (this PR touches the workflow's own path filter, so merging it will itself open a pin PR).

🤖 Generated with Claude Code

[bwhitman]

⛓️ tulipcc integration PR opened

This merge was pinned into tulipcc for full-system CI: shorepine/tulipcc#1217

Test it there and merge that PR to move tulipcc onto this AMY.