Clean up formatter contracts and guidance after context-view refactor #454

Context

Follow-up to #353. Context views now choose what enters the prompt, its order, which content may be dropped to fit a budget, and where caching ends. Formatters should serialize that already-selected content, not silently make those decisions again.

The separation is useful, but several formatter names, comments and instructions still describe the old behavior. This creates confusion for both users and the model.

Proposed work

• Keep the view and formatting configuration separate. ContextView.assemble() owns prompt selection and placement. RenderConfig selects block/message formatting. Python-value-to-text serialization remains a separate helper (context_text() or application code). Final provider encoding and retained reasoning/tool-call data remain in the client/replay layer.
• Remove duplicated XML implementation. CachedBlockFormatter and XMLBlockFormatter now have equivalent serialization. Keep the legacy name/import as a compatibility wrapper initially; XML versus Markdown should not decide whether caching works.
• Make default instructions match the selected format. Agent currently hardcodes XML guidance. BlockFormatter.format_description() says its description is included in the default system prompt, but production code does not call it. Make base instructions format-neutral, and let the default view explicitly include any selected formatter guidance. Respect prompt overrides/disables; do not secretly inject instructions into custom views.
• Update public contracts. BlockFormatter still describes choosing message order, partitioning system blocks and receiving renderer-truncated input. Those responsibilities changed in refactor(context): introduce composable context views #353. Update RenderConfig, RenderedMessage, plain-format examples and related docs to describe actual behavior. Clarify that context_text() bounds non-string serialization, not existing string length.
• Correct provider-input typing without losing replay data. The formatter/client boundary can contain ordinary messages, retained LLMResponse objects and CacheBoundary markers, not just dictionaries. Keep original reasoning and tool argument data intact rather than flattening it to satisfy a type annotation.
• Document the tool-history exception precisely. A canonical assistant tool-call response and linked results form one replay group. Stock formatting may safely omit incomplete groups. Clearly distinguish this from arbitrary reordering or inventing missing results, and keep wrapper-style customization from having to duplicate tool-replay rules.

Acceptance criteria

• XML and Markdown configurations receive matching default guidance; custom views receive no implicit guidance.
• Changing XML/Markdown formatting does not change history membership or cache-boundary placement.
• Legacy CachedBlockFormatter imports remain usable and match XML serialization.
• Updated API docs and typing match the actual order-preserving pipeline and its replay exception.
• Tests retain exact native reasoning/tool argument data and cache markers through formatter changes, including complete multi-tool turns.
• Formatter selection remains usable through RenderConfig without requiring users to write a new context view.

Scope

This is a focused cleanup, not a new formatting framework. Do not require a new arbitrary-object serializer interface, a model-specific prompt-adapter stage, per-method formatter configuration, or a broad replay rewrite. Those can be considered separately if a concrete use case requires them. The cache-boundary bugs reported on #353 should be fixed on the PR rather than deferred to this cleanup.

Starting points (reviewed at 252b3fa94)

• RenderConfig
• BlockFormatter contracts and guidance
• CachedBlockFormatter
• Hardcoded agent format guidance
• Context materialization helper
• Runtime formatter selection