fix: two boot/federation log errors — duplicate-key upserts and peer-pull denial spam

[atomantic]

Summary

Fixes two unexplained error lines in the running instance's PM2 logs.

1. 🪄 catalog migrations failed at boot: ON CONFLICT DO UPDATE command cannot affect row a second time

Postgres refuses a multi-row INSERT … ON CONFLICT (key) DO UPDATE whose VALUES list names the same conflict key twice. Two places build exactly that statement from data that makes no uniqueness promise:

• mediaAssetIndex reconcile batches every on-disk image + video into chunked upserts. One repeated gallery filename or video-history id threw, and because it is the last step of the boot catalog-migration block, the throw aborted the block and left the media asset index permanently stale — it never upserted or pruned again.
• memorySync.applyRemoteChanges batches a remote peer's payload inside a transaction, so one repeated id there rolls back the entire apply — not just its batch — every sync cycle, for as long as the peer keeps sending it. This one had no test coverage at all.

Both now collapse duplicates first through a shared dedupeByKey helper in server/lib/arrayUtils.js. Tie-break differs per table because the conflict rules differ: the media index keeps the last occurrence (what a sequential upsertAsset loop leaves), while memory sync keeps the newest updated_at, so a peer's payload ordering can't flip a last-writer-wins outcome. An unparseable clock sorts below every real one rather than NaN-comparing false and winning — otherwise a malformed copy displaces a good one and then fails the statement on a row we already had intact.

2. ❌ Route error [GET /api/sync/usage/checksum]: peer not authorized for this record

A peer that can't be identified re-polls its sync categories every few seconds, and every denied pull logged this at error level — roughly every 10s per category, forever. peerPullAuthorization already logs a deliberately throttled 🔒 line (once per caller per boot) for exactly this, so the route-level line added nothing and buried real errors.

The 403 is now severity: 'warning', the existing errorHandler mechanism for expected, already-classified denials (precedents: mediaJobs.js, imageClean.js, remoteDesktop.js). The response the caller receives is unchanged.

Strict mode previously threw with no log at all — combined with the above that would leave a user who enabled federation.strictPullAuthorization with no indication of why a peer stopped syncing. It now logs the same throttled refusal alwaysEnforce does, which collapses the two identical enforce branches into one.

Test plan

• server/services/memorySync.db.test.js — new DB-backed suite for applyRemoteChanges (the federation write path had none): duplicate id doesn't abort the transaction, tie-break is by updated_at not payload order, malformed clock loses, and the existing last-writer-wins behavior still holds.
• server/services/mediaAssetIndex/db.test.js — reconcile survives repeated refs on disk.
• Both regression tests were verified to fail with the exact production error (ON CONFLICT DO UPDATE command cannot affect row a second time) when the dedup is removed, then pass with it.
• server/lib/arrayUtils.test.js — dedupeByKey unit tests incl. the custom-comparator path.
• server/services/sharing/peerPullAuthorization.test.js — asserts the 403 carries severity: 'warning' and that strict mode now logs the throttled 🔒 line.
• npm run test:db — 32 files / 279 tests pass (includes db.guards.test.js, which validates the new DB_TEST_INCLUDE entry).
• Full server suite passes; the only failures are Python-dependent suites (imageTo3d, voice, videoGen) failing on Python was not found in this environment, unrelated to these files.

Notes

dedupeByKey lands in the existing arrayUtils.js rather than a new module, with the barrel export and server/lib/README.md row the module-maintenance rule requires. Its docblock carries the Postgres invariant so the next batching upsert site finds it instead of re-deriving the workaround.