What persistence moved or was isolated

Sprint 90 started the move, and later extraction/cleanup sprints completed the current state:

• the actual KES SQL implementation now lives in repository.ts
• KES row types and row-mapping helpers live in that same extracted repository module
• payment-note encryption/decryption handling lives in that same extracted repository module plus security.ts
• event hash-chain / integrity-adjacent helper logic lives with the extracted KES repository
• the old root delegation and svc-tenders/src/kes/* compatibility layer were later removed

Effect:

• KES route wiring now depends on a KES-owned persistence surface in the extracted runtime
• root repository.ts is no longer a KES compatibility/delegation surface
• svc-tenders no longer exposes KES persistence through TendersRepository

What still remains in the mixed root repository

No active KES persistence surface remains in repository.ts.

What remains in svc-tenders is shared backbone/runtime only, not KES repository compatibility.

What was judged mixed/shared and left in place

Left in place on purpose:

• Kafka consumer/runtime pieces under services/svc-tenders/src/kafka
• outbox relay behavior
• projection consumer behavior
• idempotency and DLQ tooling

Reason:

• these still behave like shared Kvary event-backbone infrastructure rather than a clean KES-local persistence package

What still blocks runtime/bootstrap prep

Nothing in the persistence slice still blocks runtime/bootstrap prep, because runtime/bootstrap extraction is already complete.

What remains for later is fuller KES independence:

• Kafka/outbox/projection ownership is still shared/unresolved
• auth/KYC/signature semantics are still shared
• event-backbone ownership is still shared/unresolved

Notes

• Persistence ownership is now real in the extracted runtime without pretending Kafka/outbox/projection ownership moved with it.
• Later work is backbone-transfer planning, not another root-SQL ownership pass.