fix(persistence): address PR #117 review feedback

Adopt 8 PR-agent (Qodo) findings; 4 declined (concurrency already guarded by
the putSyncedRecord/markRecordSynced guards + RPC optimistic concurrency;
SQL-injection / won-equality / microtask-race are false positives — see PR reply).

- markRecordSynced: guard on updatedAt too — softDeleteStory doesn't bump rev,
  so a same-rev newer local tombstone must not be marked synced by an older
  push's ack (symmetric with putSyncedRecord's guard)
- recordToEnvelope: fallback timestamps to 0 not Date.now() (a corrupt record
  should lose LWW, not win as "now")
- push/delete routes: validate rev/updatedAt as finite -> 400 (was silent 200);
  push: Content-Length pre-check before buffering the body
- pushDeletion: idbGet a single record instead of a full-store scan
- manifest: Cache-Control private,no-store + client fetch cache:no-store
- cloudSyncClient: Array.isArray narrowing on items/blobs
- RPC: `if found` instead of `v_row.id is not null` after RETURNING INTO

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

supabase/migrations/20260628095015_upsert_story_if_newer.sql

@@ -68,11 +68,12 @@ begin
            and excluded.updated_at > public.stories.updated_at)
   returning * into v_row;
 
-  -- v_row is populated on a fresh insert OR a winning update. It is NULL when
-  -- the row already existed AND the where-guard rejected the update (stale
-  -- write) — in that case return the current cloud row so the caller sees it
+  -- FOUND is the idiomatic PL/pgSQL test for whether RETURNING produced a row:
+  -- true on a fresh insert OR a winning update; false when the row already
+  -- existed AND the where-guard rejected the update (stale write). In the stale
+  -- case fall through and return the current cloud row so the caller sees it
   -- lost and can reconcile by pulling the newer cloud state.
-  if v_row.id is not null then
+  if found then
     return v_row;
   end if;