perf(etl): upsert social writes in place instead of demote-then-insert

[raymondjacobson]

Summary

Replaces the demote-then-insert pattern for social writes (reposts / saves / follows / subscriptions) with an in-place upsert. Each action previously did UPDATE ... SET is_current=false then inserted a brand-new row, accumulating one is_current=false row per toggle. Now it's a single:

INSERT INTO <table> (...) VALUES (...)
ON CONFLICT (<identity>) WHERE is_current = true
DO UPDATE SET is_delete = EXCLUDED.is_delete, created_at = ..., txhash = ..., blocknumber = ...

• Migration 0030 adds a partial unique index per table (... WHERE is_current = true) as the upsert arbiter. Partial on the current row only, so the "one current row per identity" invariant already holds — no dedup or backfill against existing data, and historical is_current=false rows are simply not indexed.
• Bounds table growth (one current row per identity instead of a row per toggle).
• Gives the downstream api aggregate triggers an O(1) is_delete transition to track instead of a count(*) recount.

Companion PR (deployment order matters)

Pairs with AudiusProject/api#898, which switches handle_repost/handle_save/handle_follow to transition-aware deltas + AFTER INSERT OR UPDATE. This PR must deploy first — those triggers only produce correct counts once writes are in-place upserts.

Validation

• go build ./... clean.
• Full entity_manager Repost/Save/Follow/Subscription test suite passes.
• Manually verified against Postgres: repost → unrepost → re-repost yields 1 row (not 3) with the latest txhash and correct is_delete; the partial unique index lets legacy is_current=false rows coexist and blocks a second is_current=true row.

Test plan

• CI green.
• Migration 0030 applies cleanly against a prod-shaped DB (index build time on large reposts/saves/follows tables is the main thing to watch).
• Re-delivery of the same chain tx is idempotent (DO UPDATE writes identical content).

🤖 Generated with Claude Code