fix(agent): free the LLM's VRAM on the normal path after a workflow runs

[kevin9327]

What

The in-app assistant's LLM-VRAM unload never runs in the normal case. When the assistant dispatches a workflow it's supposed to free the Ollama model's VRAM so the workflow gets the full GPU — but that only happens on the rare "reached max iterations" path, so on a single-GPU machine the LLM keeps holding VRAM while the workflow tries to generate.

Why it triggers

In agent_chat, the unload block sits after the tool-call for loop:

for _ in range(10):
    ...
    if not tool_calls:
        return AgentChatResponse(...)   # normal exit — returns from *inside* the loop
    for tc in tool_calls:
        ... execute_tool ...

has_workflow = any(a.tool == "run_workflow" for a in actions_done)   # only reached if the loop runs out
if has_workflow:
    await client.post(.../api/generate, json={"keep_alive": 0})       # "so the workflow has full GPU memory"

The normal flow is: round 1 the model calls run_workflow; round 2 it produces a final answer with no tool calls, so the function returns from inside the loop at the if not tool_calls branch. The block after the loop is only reached when all 10 iterations complete without a final answer — the "Reached maximum tool iterations." case. So the documented VRAM unload is effectively dead code in real use.

Fix

Extract the unload into _unload_llm_after_workflow(...) and call it on both exits — the normal early return and the loop-exhausted return — when a workflow was dispatched. It stays best-effort (never fails the chat) and fires only once the agent has finished reasoning, so intermediate tool rounds still have the model loaded.

Verification

• Added api/tests/test_agent_workflow_unload.py (unittest + httpx.MockTransport, scripting the Ollama /api/chat turns and recording /api/generate calls). test_llm_unloaded_on_the_normal_return_after_a_workflow fails before (no unload on the early-return path) and passes after; test_no_unload_when_no_workflow_was_dispatched guards against unloading when nothing ran.
• python -m unittest discover -s tests in api/ (venv with fastapi + python-multipart + httpx): all pass, 0 failures.