fix(node): anchor the real old_sha and issue a per-ref certificate

[beardthelion]

Refs #26 (integrity subset only; the issue stays open for the foundation work).

What was wrong

The push handler built the Arweave anchor from a copy of the ref updates that had already dropped the real old_sha, then hardcoded old_sha to 64 zeros. The signed RefCertificate with the real old -> new stayed local. On top of that, a multi-ref push only ever produced one certificate (for the first ref), and an empty push signed a timestamp string as new_sha. The 64-zero placeholder was also the wrong width: git object ids are 40-hex SHA-1.

What this changes

• Thread the parsed old_sha through the clone moved into the anchoring task, so the anchor records the real old -> new transition. This drops the "0".repeat(64) placeholder and fixes the width mismatch.
• Issue a signed RefCertificate for every ref the push advanced, each carrying that ref's real old/new, instead of one cert for the first ref.

No new dependencies, no schema or config changes.

Scope

Deliberately the integrity subset of #26. Carrying the signed certificate on Turbo, capturing the pusher signature, chaining certificates, and gl-side verification against the anchor remain open under #26.

Tests

• New arweave::tests::test_anchor_body_carries_real_old_sha locks the anchor-body contract: the upload must serialize the real old_sha/new_sha, never a placeholder.
• Full gitlawb-node suite green (126 passed); fmt and clippy clean.

The per-ref certificate issuance and old_sha threading live in the git_receive_pack handler, which has no test harness (it needs a live Postgres and git), so those are verified by compile and review rather than an automated test.

[coderabbitai]

Warning

Review limit reached

@beardthelion, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 24 minutes and 4 seconds. Learn how PR review limits work.

To continue reviewing without waiting, enable usage-based billing in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: ef1e2480-042b-40c5-8b76-adf2ce955eac

📥 Commits

Reviewing files that changed from the base of the PR and between e37ea7f and 31ed541.

📒 Files selected for processing (2)

• crates/gitlawb-node/src/api/repos.rs
• crates/gitlawb-node/src/arweave.rs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/arweave-anchor-real-oldsha-per-ref-cert

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}