fix(webui+memory): close post-turn utility process groups (memory memorization renders as in-flight "Processing...")

[Zenetusken]

Problem

After a turn fully completes (final response delivered, status bar on "Waiting for input"), the memory plugin's post-turn memorization jobs render as an in-flight phase: a process group titled "Processing..." with a UTL badge appears, its utility items ("No useful information to memorize." / "No successful solutions to memorize.") keep the shiny in-flight animation, and the group never gets an END badge. The turn is over, but the UI says it isn't.

Root cause

The monologue_end extensions _50_memorize_fragments and _51_memorize_solutions log a utility item synchronously at loop end and fill it in seconds later from a background task (DeferredTask). By then the turn's process group was already completed by the final response, so drawProcessStep opens a new process group for these items. That group:

1. contains no agent-type steps, so updateProcessGroupHeader never replaces the "Processing..." placeholder title (it only reads headings from agent steps), and
2. is never marked complete — completion only happens when a response attaches to the group, a user message arrives, or a step with kvps.finished is drawn (drawMessageInfo). Utility items carry no terminal marker, so nothing ever closes the group.

An uncompleted group keeps shiny-text on its newest step (removed only on completion), which is the perpetual flashing, and never receives the END badge.

A secondary status-bar issue: the utility item creation and its error-path warning log use the default update_progress="persistent". The error path in particular logs a new warning item after monologue_end reset progress to "Waiting for input", pinning the progress line to the warning with progress_active=true until the next turn.

Fix

Backend (plugins/_memory/extensions/python/monologue_end/_50/_51):

• every terminal update path now emits finished=True (early returns for empty/invalid/unparseable results, a single post-loop marker after successful inserts, and the exception path);
• the log item is created with update_progress="none", the terminal marker uses update_progress="none", and the error-path warning no longer hijacks the status bar.

Frontend (webui/js/messages.js):

• drawMessageUtil calls completeLastProcessGroup() when a utility step arrives with kvps.finished (mirroring drawMessageInfo); the finished kvp is hidden from the displayed data;
• updateProcessGroupHeader and the full-log classifier fall back to the last step's title when a group has no agent steps, so utility-only groups show e.g. "Memorization completed: …" instead of "Processing...".

Turn-start preload utilities are unaffected: they still join the next turn's group via the existing utility-only promotion path, and mixed groups still title from the last agent step.

Tests

tests/test_post_turn_utility_group.py (9 tests):

• runs the real memorize() coroutines of both extensions against stubbed agents: empty result, successful insert (non-consolidation), and provider-error paths each emit exactly one terminal finished marker, entries are inserted before the marker, and warnings stay off the status bar;
• asserts execute() creates the log item with update_progress="none";
• extracts the real updateProcessGroupHeader/isProcessGroupComplete/completeLastProcessGroup from messages.js into a Node fake-DOM harness: a utility-only group titles from its last step, completes with an END badge, and sheds all shiny classes; a mixed group still titles from the last agent step.

Discriminating: all 9 fail on pre-fix sources (the frontend assertion reproduces the exact reported symptom: title stays 'Processing...'), all 9 pass with the fix.

Full suite: pre-existing collection breakage on current main is unrelated to this change (8 files — email_parser_test, rate_limiter_test (real network call), test_run_ui_config, test_state_sync_handler, test_state_sync_welcome_screen, test_ws_csrf, test_ws_manager, test_ws_security — fail identically on pristine main). The remainder of the suite passes; see PR checks/comment.

Evidence of the bug (live, before fix)

Finished chat log: the final response item carries kvps.finished: true; the memorize utility items appended after it have id: null and no terminal marker, and their updates arrive after monologue_end reset progress — matching the orphaned group the UI renders.

[Zenetusken]

Full-suite regression evidence (v2.8 image harness, pytest tests/):

• Pre-fix main: 73 failed, 1099 passed, 12 errors
• This branch: 64 failed, 1108 passed, 12 errors
• Sorted failure lists are identical except for the 9 new tests (which fail on pre-fix sources by design). No pre-existing failure is fixed or introduced by this change.

Pre-existing on pristine main (unrelated drift vs the v2.8 runtime image): 8 collection-error files (email_parser_test, rate_limiter_test — performs a real OpenRouter call at import, test_run_ui_config, test_state_sync_handler, test_state_sync_welcome_screen, test_ws_csrf, test_ws_manager, test_ws_security) plus 64 runtime failures (test_time_travel and others), all byte-identical before and after this patch.