Persist notification email batches with leased idempotent delivery

docs/quality/uygulama-durumu.md

@@ -814,3 +814,10 @@ Taslak türü seçicisine erişilebilir ad eklendi. Üretim derlemesi geçti. Ö
 - Resend belgelerine göre idempotency anahtarları 24 saat tutulur: https://resend.com/docs/dashboard/emails/idempotency-keys . Bu nedenle kalıcı kuyruğun süresi dolan belirsiz işi sessizce yeniden göndermemesi gerekir.
 - 183 otomatik test geçti. Gövdenin 25 kaydı kapsaması, HTML kaçırma, gönderici/anahtar aktarımı ve eksik gönderim kimliği hatası kontrollü testlerle doğrulandı. Gerçek e-posta gönderilmedi.
 - Anahtar desteği henüz notifier'ın kalıcı gönderim kaydına bağlanmadı; kalıcı outbox işi açık. Bu değişiklik tekrar gönderimin bütünüyle önlendiği anlamına gelmez.
+
+### Kalıcı abonelik e-postası kuyruğu — 6 Eylül 2026
+- notification_outbox notify.sqlite'a eklendi. İçerik, gönderen, alıcı, ihale grubu ve UUID kalıcıdır; retry güncel şablonu/ilanı kullanarak metni değiştirmez. Resend Idempotency-Key aynı UUID'den üretilir.
+- Abonelik başına tek aktif grup unique index ve transaction ile korunur. 120sn işçi sahipliğiyle ikinci işçi aynı grubu üstlenemez; geç eski işçinin başarı/hata kaydı reddedilir. Sağlayıcı kabulü ve görülen ihale listesi aynı transaction'da tamamlanır. Eski abonelik listesiyle çalışan işçi daha önce işaretlenmiş grubu yeniden oluşturamaz.
+- İlk çağrıdan 23 saat geçmiş belirsiz grup otomatik yeniden gönderilmez; abonelik listesinde inceleme gereksinimi gösterilir. Abonelik silinince bekleyen grup iptal edilir; hâlihazırda sağlayıcıya ulaşmış isteği geri çekme garantisi yoktur.
+- 186 test ve üretim derlemesi geçti. Gerçek depo/notifier + kontrollü sağlayıcıyla hata→kaynak değişikliği→aynı gövde/anahtar retry→kabul test edildi. Kaynak sabitleme, işçi yarışması, eski işçi reddi, atomik görülme, süre aşımı ve abonelik silme test edildi.
+- Gerçek Resend teslimi, gerçek SIGKILL/outbox kabulü ve belirsiz gönderimin yönetici çözüm ekranı henüz yok. Telegram ayrı kalıcı kuyrukta değil; e-posta kabulünden sonra süreç kesilirse Telegram bildirimi eksik kalabilir. Sağlayıcı hesap değişimi/geri yükleme işlemleri için runbook kısıtları eklendi. Planın tümü açık.

docs/quality/yedek-geri-yukleme.md

@@ -65,3 +65,5 @@ Bildirim ve takip taraması deposu artık `IHALEIST_USER_DATA_DIR/takip.sqlite`
 E-posta aboneliği deposu `notify.sqlite` da `IHALEIST_USER_DATA_DIR` ayarını izler; değişken yoksa eski `server/data` yolu kullanılır. Özel dizinli eski kurulumlarda yükseltmeden önce sabit yoldaki notify.sqlite tutarlı biçimde yedeklenip yeni hedefe taşınmalıdır; mevcut hedef üzerine yazılmaz. Yerel değişiklik üretim deposunu taşımadı. Bu dosya yalnız kullanıcı/belge yedeğinin kapsamına girmez, tam volume envanterinde ayrıca bulunmalıdır.
 
 notify.sqlite abonelik kimliği geçişi: `criteria_key` sütunu eklendi; konu ve kurum kümeleri dahil bütün filtreler aboneliğin kimliğine katılır. Eski tablo işlem içinde yeniden kurulur; id, oluşturulma, aktiflik, son gönderim, görülen ihaleler ve AUTOINCREMENT üst sınırı korunur. Eski eşdeğer yinelenen kayıtlar silinmez; ayrı legacy kimliğiyle korunur. Bozuk eski konu/kurum JSON'u geçişi başarısız yapar ve transaction geri alınır. Yükseltmeden önce notify.sqlite yedeği alınmalı; eski uygulama koduna dönülecekse eski unique kuralını kullanan INSERT nedeniyle yalnız kodu geri almak yeterli değildir: eşleşen eski veritabanı yedeğiyle birlikte geri dönüş gerekir. Yeni sürümde oluşan kayıtların geri dönüşte nasıl korunacağı ayrıca değerlendirilmelidir.
+
+Kalıcı e-posta kuyruğu aynı notify.sqlite içinde `notification_outbox` tablosundadır. Tam içerik/gönderen/alıcı ve ihale listesi ile sağlayıcı istek kimliği burada korunur; yedeğe dahil edilmelidir. Bir bekleyen grup abonelik başına tek aktif kayıtla tutulur. 120 saniyelik işçi sahipliği, 30 saniyelik sağlayıcı isteğinden uzundur. İlk denemeden 23 saat sonra belirsiz kayıt otomatik tekrar gönderilmez; Resend'in 24 saatlik tekrar önleme süresine güvenli pay bırakılır. Yönetici sağlayıcı kaydını doğrulamalıdır; belirsiz kaydın elle çözüm ekranı henüz yoktur. Bekleyen iş varken sağlayıcı hesabı/anahtarı değiştirilmemelidir: tekrar önleme anahtarı farklı sağlayıcı hesapları arasında garanti vermez. Eski uygulamaya dönmek kuyruğu yok sayabileceğinden kod ve DB geri dönüşü birlikte değerlendirilmelidir.