fix(ddl): remove duplicate is_current rows from users

[rickyrombo]

Pairs with OpenAudio/go-openaudio#433, which adds users_current_uniq_idx to stop this recurring.

What

users_pkey is (user_id, txhash), which admits a second is_current row under a different txhash. Five users have one, spread 2025-06 → 2026-06.

Five rows, but the blast radius isn't five rows — anything joining an entity to its owner's wallet fans out and silently duplicates every entity those users own. Measured on a production clone:

	with dedupe	plain join	phantom rows
tracks	1,955,896	1,955,914	+18
follows	26,067,177	26,067,964	+787

Why the delete is here and not in the ETL migration

ETL migrations run automatically at indexer start (SkipMigrations is left false), so shipping the delete there would make a go get silently remove rows from this database. The index stays in the ETL migration — it's that module's invariant — and the one-time repair lives in the application that owns the data.

Ordering

The index cannot be created while duplicates exist, so this must run first. It does: ddl migrations run in the pre-roll migrate Job that every serving Deployment DependsOn, while the ETL's run at indexer start after that Job completes.

Verified both orders against a fixture:

index first          -> ERROR: could not create unique index ... Key (user_id)=(98311147) is duplicated
backfill then index  -> both apply; violations 0; indisvalid = t
re-running either    -> no-op

Choices

• Deleted, not demoted. users keeps no versioned history — the indexer writes it in place and production has zero is_current = false rows — so demoting would leave a category of row nothing reads.
• Safe to delete. No foreign key references users; its triggers are AFTER INSERT (on_user) and AFTER INSERT OR UPDATE (trg_users), so a delete fires neither.
• Winner is the highest blocknumber, matching how consumers pick the live row. On the clone, blocknumber and updated_at agree in all five cases, and for user 666149592 it keeps is_deactivated = true — the later of that pair's states.

Cause is not established

Both indexer create paths reject an existing user (validateUserCreate and migratedUserCreateHandler both call userExists), so a single writer can't produce these — its check and insert share a transaction. A second writer can, since check-then-act isn't atomic across transactions; three of the five pairs put a bare-hex txhash next to a 0x-prefixed one, which fits but doesn't prove it. The index will surface it if it recurs.

🤖 Generated with Claude Code

[rickyrombo]

Superseded by #1011, which combines this with the other two api-side changes. They're only correct together in one deploy — merging the module bump without the users backfill would fail ETL migration 0035's index creation and stop the indexer starting.