Extract agent-input pipeline; remove ghost provider_render_kb

[zomars]

Parent

#12

What to build

One module owns the construction of LLM input for an agent + task. A single entry point takes (agent_key, canonical Issue file, instance label, runtime mode) and returns the system prompt and the initial message ready to hand to claude.

The module composes:

1. The agent's prompt file.
2. The active provider's instructions overlay (when present).
3. The agent's learnings file (when non-empty).
4. The rendered Issue block via issue_render_inline from the existing Issue renderer.
5. The initial message string with the rendered Issue embedded and the instance/CWD context.

Three current callers — interactive ralph run, ralph debug --preview-prompt, and the AFK loop's loop_build_context — collapse into thin shims that delegate to this module.

The ghost provider_render_kb call (today resolves to the empty string in two of those callers) is removed, not implemented. Rendering belongs on the Issue renderer seam, which is already provider-agnostic.

Acceptance criteria

• New module exists with a single public entry point that takes agent_key, canonical Issue file path, instance label, runtime mode, and emits system prompt + initial message.
• bin/ralph:cmd_run delegates to the new module — no inline prompt assembly, no provider_render_kb call.
• bin/ralph:cmd_debug --preview-prompt delegates to the new module — no inline prompt assembly, no provider_render_kb call.
• lib/ralph-gated-loop.sh:loop_build_context delegates to the new module.
• Interactive ralph run now includes the rendered Issue block in its initial message (regression fix for the silent ghost-function bug).
• ralph debug --preview-prompt output matches what the AFK loop would send for the same (agent, task, instance) byte-for-byte except for the worktree-vs-project-root CWD line.
• Behaviour-level tests cover: prompt assembly order (prompt → provider instructions → learnings); presence/absence of optional sections (no provider instructions, empty learnings); rendered Issue block present in the initial message; the three caller invocation shapes produce the expected outputs.
• Tests use fixture inputs (canonical Issue JSON, fake prompt/learnings files), no live tracker, no live claude.
• Tests follow the existing tests/ harness conventions — no new framework, no build step.
• CONTEXT.md updated to name the new module under a new section (or under an existing one, implementer's call); the Issue renderer section unchanged.

Blocked by

None — can start immediately.