fix(actions): lock the objective row before computing effective_closed

[lucca65]

Summary

Closes the dual-writer race against the backend's objective completion. Inside upsertAction's transaction, the first statement is now:

const freshObjective = await tx.instance.oneOrNone(
  'SELECT id, is_completed FROM objectives WHERE id = $1 FOR SHARE',
  [payload.data.objective_id]
)

The FOR SHARE lock conflicts with the backend's row lock when Objectives.complete_objective/2 flips objectives.is_completed, so the two writers serialize on that row: whichever commits first, the loser re-reads the committed state under READ COMMITTED, and the stale-snapshot insert (indexer reads incomplete → backend completes → indexer inserts effective_closed=false) is impossible.

• effective_closed is derived from the post-lock read; the null-objective fallback to the top-of-function fetch is preserved (a drifted objective must never crash-loop the indexer).
• tx.instance.oneOrNone, never .one — pg-promise's .one throws on zero rows, which would roll the block back and retry forever.
• The backend bounds the wait with a 5s lock_timeout on its finalize transaction plus Oban retry.
• last_tx/last_eos_account were already stamped on both create and update paths (fix(provenance): stamp last_tx/last_eos_account on objective and action writes #71); no change needed.

Verified

• yarn format (StandardJS) clean.
• git diff shows only src/updaters/community.js.

Deploy after the backend schema lands (migration → restart event-source → backend app).