Post-stream message reload is dead code: window.chatMessages.loadMessages is never exported

@paullizer is already working on this.

Since Aug 18, 2026.

## Issue

`chat-streaming.js` guards its post-stream message reload on a function that does not exist, so the reload never happens.

Both call sites look like this:

```js
if (finalData.reload_messages && finalData.conversation_id
&& typeof window.chatMessages?.loadMessages === 'function') {
window.chatMessages.loadMessages(finalData.conversation_id);
}
```

- `application/single_app/static/js/chat/chat-streaming.js:1449` (generated-image branch)
- `application/single_app/static/js/chat/chat-streaming.js:1515` (standard assistant branch)

`window.chatMessages` is assigned in `chat-messages.js` and exposes exactly six functions:

```js
window.chatMessages = {
applyMaskedState,
applySearchHighlight,
appendMessage,
clearSearchHighlight,
extractSuggestedFollowUpPrompts,
scrollToMessageSmooth
};
```

`loadMessages` is not among them. `typeof` is therefore always `undefined`, the condition is always false, and the reload is dead code.

`git log -S "loadMessages,"` on `chat-messages.js` returns nothing, so `loadMessages` was **never** exported on that object. This is not a regression — the guard has never worked since it was introduced in commit `54e37c87` ("made streaming primary").

## Expected Behavior

When the backend signals `reload_messages: true`, the browser should refetch the conversation so messages the plugin persisted directly into Cosmos become visible without a manual page reload.

## Actual Behavior

Nothing happens. Those messages stay invisible until the user reloads the page or reselects the conversation.

## What sets `reload_messages`

`route_backend_chats.py:20082` sends `'reload_messages': reload_messages_required`, which is set at `route_backend_chats.py:19283-19287` when any agent plugin result trips `result_requires_message_reload()`. That helper is documented as:

> "Heuristically detect plugin outputs that inject new Cosmos messages (e.g., chart images)."

It returns `True` for payloads carrying `reload_messages`, `requires_message_reload`, `metadata.requires_message_reload`, a non-empty `image_url`, `type == 'image_url'`, or a `mime` starting with `image/` — recursively through dicts and lists.

## Impact — needs sizing before a fix

Impact is likely narrower than it first appears, and should be measured rather than assumed:

- The final-payload handler separately renders `finalData.image_url` via `appendMessage('image', ...)` at `chat-streaming.js:1433`, so a single generated chart probably still displays.
- The breakage is limited to **additional** message documents a plugin persisted beyond what the streaming payload carries.

Collaborative conversations are not affected by this specific path: the collaboration bridge sets `'reload_messages': bool(stream_payload.get('error'))`, and any payload carrying `error` short-circuits earlier at `processStreamData`'s `if (data.error)` branch.

## Suggested Approach

1. Build a repro: a plugin whose result trips `result_requires_message_reload()` and writes an extra message document, then confirm what is actually missing from the transcript.
2. Only then decide the fix. Exporting `loadMessages` on `window.chatMessages` is a one-line change, but it switches on a code path that has never executed in production — worth checking for double-rendering, scroll jumps, or interference with streaming state before enabling it.
3. Add a functional test asserting the guarded symbol is actually exported, so a dead guard like this cannot ship again.

## Notes

Found while fixing #1281 (PR #1283). Deliberately left out of that PR because it is unrelated to the shared-conversation defects and needs a repro to size correctly.