translator: an async systemPrompt builder with collection, document and run context

[denis-urban]

Read against 0.10.1.

Problem

Two seams see less than a host needs, and together they make prompt customisation per collection or
per run impossible.

SystemPromptBuilder is synchronous, and its whole context is:

{ sourceLang, targetLang, defaultPrompt }

No payload handle, no collection, no document. So nothing can be read from the CMS inside it. A
builder that closes over a cache does not help, because it cannot await a cache warm — the first call
after a cold boot would use an empty cache and say nothing about it.

The provider sees text and nothing else. translate(input, sourceLng, targetLng) where
input: Record<number, string> — bare indexed strings, no collection, no document id, no run
reference.

Why this matters

We inject a terminology glossary into the system prompt. Because of the two facts above:

• We cannot use systemPrompt at all, and instead wrap TranslationProvider with our own async
  translate that resolves the glossary and constructs createOpenAIProvider per call with the terms
  baked into a closure. That works, but the wrapper exists purely to get an await.
• Per-collection and per-run glossary scoping is unimplementable at any price. A term that should
  apply to machine-model pages but not to careers listings cannot be expressed, because nothing at
  either seam knows which collection is being translated. This is not a workaround we have not found;
  the information is not present.

Suggested shape

Make systemPrompt awaitable, and widen its context:

type SystemPromptContext = {
  sourceLang: string
  targetLang: string
  defaultPrompt: string
  collection?: string
  documentId?: string | number
  payload?: Payload
}

type SystemPromptBuilder = (ctx: SystemPromptContext) => string | Promise<string>

Accepting a promise is backwards-compatible with existing synchronous builders. Passing the same
context through to TranslationProvider.translate would close the gap on the provider side too.