Cleanup findings from #100 review (reuse, simplification, efficiency)

[IRus]

Summary

Addresses the five cleanup findings from the #100 review that were deferred from the bug-fix PR (#101, now merged). Branch is off fresh main, so it builds on those fixes. Each change was delegated to codex and reviewed; behavior-preserving refactors are guarded by the existing suite (with characterization tests added where coverage was thin), and behavioral changes have their own tests. Full ./gradlew :test passes.

Changes (one commit each)

1. Drop duplicated maxSequentialBookErrors — the abort threshold (100) was serialized into every job-status snapshot while the admin UI also hardcoded its own || 100. Removed the serialized field; the "Error Streak" metric now shows a plain count. The constant stays where it is used (the parser abort).

2. Build the embedding translator delegate lazily — AutoTokenTypeTextEmbeddingTranslator eagerly built both the with/without-token-type variants but uses only one, fixed once the model is inspected. Now memoizes the single needed delegate on first prepare() with volatile double-checked locking. (Kept the shared-instance semantics because per-thread predictors share this one translator — a naive per-prepare() rebuild would have been a concurrency hazard.)

3. Stream the base64 attachment — buildRawEmail held the attachment ~4-5× in memory (raw bytes + base64 String + StringBuilder + final toByteArray). It now writes straight to a ByteArrayOutputStream via Base64.getMimeEncoder().wrap(...). Output bytes are unchanged; a new round-trip test guards the base64 body.

4. Share one Ktor-based Content-Disposition helper — the email path hand-rolled rfc2231FileName and its own filename/filename* branching, duplicating what Ktor's ContentDisposition (already used by the download route) does. Added attachmentContentDisposition(fileName, includeAsciiFallback) in util, used by both the download route (fallback + filename*) and buildRawEmail (extended-only for Kindle), and deleted rfc2231FileName.

   • Note — intended wire-format change: the Kindle email Content-Disposition now renders in Ktor's RFC-compliant form: lowercase filename*=utf-8''… (was UTF-8'') and unquoted token filenames (filename=Clean_Title.epub instead of quoted). The percent-encoded bytes and the extended-only-for-non-ASCII behavior that Fix mojibake Kindle titles and other book-delivery improvements #100 validated for Kindle are unchanged; only the RFC-5987 charset case and token quoting differ (both standards-compliant). Two email test assertions were updated to match.

5. Consolidate filename handling (finding gradle(deps): bump org.gradle.toolchains.foojay-resolver-convention from 0.10.0 to 1.0.0 #6, two commits):

   • Reuse the materialized filename for the Kindle attachment — the Kindle path re-derived the attachment filename from the raw book title, so it diverged from the HTTP-download filename (MaterializedBook.fileName) and blank titles lost the book_<id> uniqueness. sendBookToKindle now takes the canonical attachmentFileName; the worker passes materialized.fileName. The Subject still uses the human-readable title.
   • Extract shared sanitization primitives — takeCodePointSafe, WHITESPACE_RUN, and UNDERSCORE_RUN moved into util/TextSanitization.kt and reused by BookFileService.sanitizedTitle, EmailService.sanitizeBookTitle, and asciiFallbackFileName (previously each had its own copy). No output changes for any input.

Tests

• New: base64 round-trip characterization (EmailServiceTest), Kindle attachment-filename assertion (KindleSendWorkerTest).
• Updated: two EmailServiceTest disposition assertions for the Ktor format (change pip(deps): bump aiofiles from 23.2.1 to 24.1.0 in /conversion-service #4).
• All pre-existing tests stay green; full ./gradlew :test passes.

🤖 Generated with Claude Code