fix(llm): stop leaking instruction prompts instead of processed text

Running a custom instruction (translate, summarise, rewrite, explain code,
free prompt) inserted the instruction's own wording instead of the result.
Two faults stacked:

The instruction was passed as the text to process, leaving the system-prompt
argument empty. `BASE_SYSTEM_PROMPTS` has no `custom` key, so resolution fell
back to `refine` without saying so, and the model dutifully polished the
instruction it had been handed. The transcript never reached it.

And only `{{text}}` was substituted, which none of the five built-in
instructions use — they carry `{{targetLanguage}}`, `{{userPrompt}}`, or no
placeholder at all. The substitution was a no-op from the day it was written:
the presets landed ten hours before the code that expected them.

- Instruction prompts now go to the system-prompt argument and the transcript
  to the text argument. Instructions that spell out `{{text}}` keep their old
  meaning, so hand-written ones still work.
- `renderInstructionPrompt` resolves `{{text}}`, `{{userPrompt}}` and
  `{{targetLanguage}}` in one place, and warns by name when a placeholder is
  left standing rather than letting it reach the model.
- `resolveSystemPrompt` no longer drops silently to `refine` for `custom`.
- Voice shortcuts no longer die at the `defaultLLMAction === 'none'` gate; an
  explicitly named instruction outranks the default. Without one, `none` still
  passes the transcript through untouched.
- `translate` receives its target language instead of relying on a default two
  call frames away. It is still always English — `AppConfig` has no key for it,
  and neither `language` (UI locale) nor `sttLanguage` (source language) can
  stand in. Choosing a target language needs a setting and is not in this fix.
- Chains ran instructions with placeholders intact; they share the same
  resolution now.
- The command screen's pipeline bench called `llm.generate`, which preload does
  not expose, so every run threw and the catch showed the input back as if it
  had succeeded. It uses `llm.process` now, over the same path production
  takes, and a failure reads as a failure.

Present since the feature shipped: the custom-instruction path has never
worked. Plain actions (refine, summarise, grammar, expand) were unaffected and
are now covered by tests so they stay that way.

apps/desktop/src/main/services/ChainService.ts

@@ -6,6 +6,7 @@ import { getLogger } from './LoggerService'
 import { configGet, configSet } from './ConfigService'
 import { getCustomInstructionService } from './CustomInstructionService'
 import { getPremiumLLMService } from './PremiumLLMService'
+import { buildInstructionInvocation, resolveTargetLanguage } from './llm-prompts'
 import { getMainWindow } from '../windows/WindowManager'
 import { IPC_CHANNELS } from '@d3ro/core/ipc-channels'
 import { D3ROError, ErrorCode } from '@d3ro/core/errors'
@@ -151,6 +152,7 @@ class ChainService {
 
     const llm = getPremiumLLMService()
     const instructionService = getCustomInstructionService()
+    const targetLanguage = resolveTargetLanguage()
 
     logger.info(
       `Executing chain "${chain.name}" (${chain.steps.length} steps) with input length ${inputText.length}`
@@ -189,7 +191,19 @@ class ChainService {
       // LLM 호출
       const stepStart = Date.now()
       try {
-        const result = await llm.processText(stepInput, 'custom', undefined, instruction.prompt)
+        // 지시문은 시스템 프롬프트, 스텝 입력(이전 스텝 출력)은 처리 대상 텍스트.
+        // {{text}}를 쓰는 지시문은 치환 결과가 처리 대상 텍스트가 된다.
+        const invocation = buildInstructionInvocation(
+          instruction.prompt,
+          stepInput,
+          targetLanguage,
+        )
+        const result = await llm.processText(
+          invocation.text,
+          'custom',
+          undefined,
+          invocation.systemPrompt,
+        )
         const stepDuration = Date.now() - stepStart
 
         stepResults.push({