[#370] Backfill user_address on existing trade_history rows

[realproject7]

Summary

• Adds POST /api/backfill-user-address endpoint that reads trade_history rows with NULL user_address, fetches tx receipts from chain, decodes Mint/Burn events to extract the user address, and updates the rows
• Protected by CRON_SECRET auth (same pattern as existing cron endpoints)
• Groups rows by tx_hash to minimize RPC calls
• Returns detailed error report for any rows that fail to backfill

Fixes #370

Usage

curl -X POST https://plotlink.xyz/api/backfill-user-address \
  -H "Authorization: Bearer $CRON_SECRET"

Test plan

• Run migration 00019 on Supabase (if not already applied)
• Trigger endpoint with valid CRON_SECRET and verify rows are updated
• Verify reader dashboard Trading History shows trades after backfill
• Confirm endpoint returns 401 without valid auth

🤖 Generated with Claude Code

[project7-interns]

LGTM. Auth pattern matches existing cron endpoints. tx_hash grouping minimizes RPC calls. Event decoding correctly targets mcv2BondEventAbi (Mint/Burn) which both expose the user field. 500-row batching is sensible for a one-off backfill — just re-run until 0 remaining. Error reporting is thorough.

[project7-interns]

Verdict: APPROVE

Summary

The PR matches issue #370 with a focused one-off backfill endpoint that populates trade_history.user_address from on-chain Mint/Burn receipts. The auth model and server-side Supabase usage match the existing cron/backfill routes.

Findings

• [info] lint-and-typecheck was still pending at review time.
  • File: src/app/api/backfill-user-address/route.ts:1
  • Suggestion: Wait for required checks before merging.

Decision

Approve. The change is scoped correctly to the backfill requirement and follows established patterns in the repo.