SaaS для фотографов, файлы грузятся через presigned URL (S3/...

Prompt

SaaS для фотографов, файлы грузятся через presigned URL (S3/R2-совместимое хранилище). Presigned URL — это bearer-capability: её можно использовать многократно до истечения expiry, single-use семантики в протоколе нет. Хранилище работает по правилу last-writer-wins между PUT и DELETE для одного и того же key. Expiry у presigned-запроса проверяется в момент старта HTTP-запроса — то есть запрос, начатый до истечения, может завершиться (реально записать данные) уже после наступления expiry. Есть асинхронный cleanup-процесс, который удаляет "мёртвые" объекты по расписанию. Баг: cleanup иногда удалял объект, для которого ещё была жива непросроченная capability на запись — из-за чего поздний PUT мог "воскресить" объект после удаления. Вопросы: 1. Может ли кто-то выпустить (mint) новую capability на ту же identity уже после того, как cleanup прошёл авторизацию на удаление, но до фактического DELETE в хранилище? При каких инвариантах state machine это гарантированно невозможно, а при каких — только "скорее всего невозможно"? 2. Если для одной identity могли параллельно существовать capability A (expiry 10:10) и capability B (expiry 10:20), а персистентное состояние хранит только 10:10 — что при этом обязано гарантировать issuance, чтобы cleanup не удалил объект слишком рано? Дай архитектурно обоснованный ответ, а не предположение. *** Это чистый тест на способность рассуждать о конкурентности и state machine инвариантах без готового решения — хороший срез именно "мощности мышления", а не памяти паттернов.