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/ipc/llm-handlers.ts

@@ -7,6 +7,7 @@ import { getLocalLLMService } from '../services/LocalLLMService'
 import { getPremiumLLMService } from '../services/PremiumLLMService'
 import { getOnlineLLMService } from '../services/OnlineLLMService'
 import { configGet, configSet } from '../services/ConfigService'
+import { buildInstructionInvocation, resolveTargetLanguage } from '../services/llm-prompts'
 import { normalizeLoopbackUrl } from '../utils/loopback'
 import { getMainWindow } from '../windows/WindowManager'
 import type { SetLLMModelParams, SetServerUrlParams, LLMProcessParams } from '@d3ro/core/types'
@@ -87,11 +88,23 @@ export function registerLLMHandlers(): void {
         backend === 'online' ? getOnlineLLMService() : getLocalLLMService()
       const start = performance.now()
 
+      // 지시문 프롬프트를 시스템 프롬프트 자리로 보내고 플레이스홀더를 치환하는 판단은
+      // VoiceModeService·ChainService와 같은 함수를 쓴다. 렌더러는 지시문 원문만
+      // 넘기고, 치환 규칙을 복제하지 않는다.
+      const invocation =
+        params.action === 'custom' && params.customPrompt
+          ? buildInstructionInvocation(
+              params.customPrompt,
+              params.text,
+              params.targetLanguage ?? resolveTargetLanguage()
+            )
+          : { text: params.text, systemPrompt: params.customPrompt }
+
       const processedText = await service.processText(
-        params.text,
+        invocation.text,
         params.action,
         params.targetLanguage,
-        params.customPrompt
+        invocation.systemPrompt
       )
 
       return ipcSuccess({