F6: fix two replay bugs — genesis-index users FK, created_tx rewrite on edit

[lucca65]

F6 — Two pre-existing replay bugs: both confirmed, both fixed

From the follow-up handoff — two second-hand reports from the escrow indexer work. Both reproduce; evidence and fixes below. Two commits: e982794 (bug 1), b120dd4 (bug 2). yarn format clean.

Bug 1 — community creator missing from users on a fresh genesis index: CONFIRMED

Reproduction (before): fresh schema-only DB, index from block 1. Local chain's first real action is cambiatus.cm::create at block 104 (creator alice):

Cambiatus >>> Create Community 104
Something went wrong while creating community
  ... code: '23503', constraint: 'network_account_id_fkey',
  detail: 'Key (account_id)=(alice) is not present in table "users".'   <- swallowed by .catch(logError)
Cambiatus >>> New Netlink 104
An error has occured. error is: ... "network_community_id_fkey"
  detail: 'Key (community_id)=(0,TST) is not present in table "communities".'
Process will exit now.                                                   <- unhandledRejection -> logExit

Result: 0 users, 0 communities, 0 network rows — the whole createCommunity transaction rolled back (FK failure swallowed), and the very next netlink crashed the process (crash-loop under pm2). Prod never sees this because backend sign-ups pre-populate users; a genesis index of a fresh DB has no such seeding.

Fix: createCommunity now upserts the creator into users (INSERT ... ON CONFLICT DO NOTHING, same pattern as netlink) inside the same transaction, before the network/network_roles inserts.

Acceptance (after): fresh DB from block 1 — 0 exit events; 6 users, 5 communities, 19 network, 20 network_roles; alice present with created_block=104; all 5 communities indexed.

Bug 2 — upsertObjective/upsertAction rewrite created_tx on edit: CONFIRMED

Reproduction (before): created objective id=2 (tx f0332fb6…, block 32590) and action id=3 (tx bbebf474…, block 32850), then edited both (block 32950). After indexing, both rows carried the EDIT's created_block/created_tx. Then a safe rewind (UPDATE _index_state SET block_number=32589 … WHERE id=1 + targeted _processed_actions delete, per scripts/reindex-runbook.md) and replay:

Cambiatus >>> Upsert Objective 32590
Could not resolve chain objective id, falling back to serial
  Error: resolveCreatedObjectiveId: all 2 chain objectives for community 0,TST are already in the DB
Something went wrong while creating objective
  error: duplicate key value violates unique constraint "community_objectives_pkey"
An error has occured. error is: error: current transaction is aborted, commands ignored
Process will exit now.

Exactly the reported chain: edit destroyed created_tx → create guard count({created_tx})=0 on replay → create re-executes → chain-id resolution finds nothing unknown → serial fallback → pkey violation → aborted block tx → process exit → crash-loop.

On the migration comment (a decision, not silent compliance): backend migration 20260702120000_add_idempotency_backstops.exs says "the event-source update path rewrites created_tx on every edit…" — but only to justify not adding a unique index; it simultaneously relies on "the created_tx create-path guards", which the rewrite defeats. It documents current (buggy) behavior, not a design goal. The fix is therefore to stop the rewrite; the no-unique-index decision still stands on its own (two creates in one tx would legitimately share created_tx). The backend comment itself may want a follow-up touch — flagged, not changed here.

Fix: in upsertObjective and upsertAction, created_block/created_tx/created_at/created_eos_account moved out of the shared data into the create path only; update paths write just mutable fields.

Acceptance (after):

1. Provenance restored on the two vandalized rows (mirrors the prod remediation note below).
2. New create + on-chain edit under fixed code: mutable fields updated, created_tx/created_block unchanged.
3. Full rewind + replay: 0 crashes, 0 serial fallbacks, 0 duplicate keys — objectives 3 rows, actions 4 rows (no duplicates), all created_tx values intact, 8 ledger rows re-claimed.

Same-class observations (report only, not fixed)

• Prod rows already edited pre-fix keep a destroyed created_tx — their create guard is still broken. The _processed_actions ledger protects them in normal operation, but any ledger-cleared replay over their create blocks re-triggers the pkey crash-loop. Consider a one-time remediation restoring objectives/actions.created_tx (+block/at) from chain history.
• upsertRole also rewrites created_tx on every edit — same class, but benign: its guard keys on the (name, community_id) natural key.
• Most updaters still swallow errors (.catch(logError)) — the known "claimed ledger row without applied writes" window from the runbook. Pre-existing, documented, untouched.
• Local-chain-only cosmetic: rewinding with block_hash='' skips the handler's seek so the reader re-walks from block 1 (ledger makes it no-ops), and the non-monotonic cambiatus.tk history can leave _index_state at a stale low block after catch-up.