v0.3.13-pre.009

crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md -->
-<!-- version: 8 -->
+<!-- version: 9 -->
 
 # Utilisation de ksp-worker-raw-transaction-ingest-lib
 
@@ -255,6 +255,19 @@ Yellowstone Account/Ping/Pong/Entry -> sans RAW Transaction dans cette verticale
 
 Les signaux de même `(network, signature, commitment)` sont coalescés globalement avant l'hydration HTTP. Si plusieurs sources produisent ensuite la même transaction canonique, le Worker conserve une seule entité RAW et enregistre séparément les observations déterministes propres à chaque source. Le Worker ne possède pas une boucle de retry HTTP : reroutage/retry/backoff restent dans `ksp-onchain-transport-lib`.
 
+Les sources qui nécessitent `getTransaction` partagent des quotas bornés et déterministes. Pour une composition valide :
+
+```text
+nombre de sources avec hydration <= admission_queue_capacity
+nombre de sources avec hydration <= persistence_concurrency
+somme de leurs pending <= admission_queue_capacity
+somme de leurs tâches d'hydration actives <= persistence_concurrency
+```
+
+Ces contraintes garantissent au moins une part à chaque source reference-bearing sans introduire de scheduler pondéré. Si les settings ne permettent pas cette répartition, le démarrage échoue avant spawn avec `runtime_invalid`; le caller doit augmenter la capacité concernée ou réduire le nombre de sources nécessitant une hydration.
+
+Pour une même identité `(network, signature)`, une divergence canonique de slot, block time, format ou hash est un `content_conflict`. Le Worker ne choisit ni majorité ni provider préféré et n'écrase pas un contenu divergent ; le Store reste l'autorité durable finale du conflit.
+
 ## Observer le snapshot concret
 
 ```rust