fix: batch gallery writes and mint rkeys client-side master
Creating a gallery was ~41 sequential requests for 10 photos — one uploadBlob, createRecord, and gallery.item per photo — and 31 of those were separate signed repo commits. That is where the minute-plus publish time came from. It also duplicated photos. Because createRecord lets the PDS assign the rkey, a replayed POST writes a second record rather than colliding with the first. One gallery in prod has the same photo at position 2 three times, written 21s and 10s apart from a single client `await`. Mint TIDs client-side and send everything in one applyWrites. Knowing the URIs up front lets gallery items reference a gallery created in the same transaction, so create, edit, and Instagram import each collapse to a single atomic call, and a replay collides on the duplicate rkey instead of writing a second copy. Verified against a real PDS: predicted URIs match the written URIs, a replayed request is rejected with the repo left untouched, and the edit path's update+delete+create applies correctly. Since a rejected replay would otherwise send the user back to press Post again — minting fresh rkeys and leaving two galleries — publish() checks whether the gallery actually landed before surfacing the error. Also fixes the service worker throwing "Failed to convert value to 'Response'": caches.match() resolves to undefined on a miss, and navigations are never precached, so any network blip during one hit it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>