test(portal): deflake cron conversation-grouping sidebar tests

[agent-farnsworth]

Closes #1573

Summary

main Build & Test was red on a single flaky bUnit test in the SignalR Blazor client conversation-grouping suite. This PR makes the affected tests deterministic. No production code changes — the fix is test-only.

Investigation — not a regression

#1573 named feat(cron): add opt-in DeleteAfterRun (#1571) as the likely culprit. It is not:

• #1571 touches only 5 files, all in BotNexus.Cron (CronJob.cs, CronOptions.cs, CronScheduler.cs, SqliteCronStore.cs, + its test) — zero BlazorClient / MainLayout.razor / .razor files. It cannot introduce a deterministic regression in a Blazor-client render test.
• MainLayout's IsUserFacingConversation / IsCronConversation predicates and the conversation-list grouping are correct at HEAD 4eb4ae9d — the virtual-kind cron conversation is correctly classified.
• The test passes 9/9 locally on 4eb4ae9d (5× the isolated CronConversations_VirtualKind_RenderedInScheduledGroup, 4× the whole ConversationGroupingTests class). It only fails under CI scheduler timing.

Root cause — async OnAfterRender re-collapse race

MainLayout.OnAfterRenderAsync(firstRender) reads localStorage["botnexus-cron-collapsed"] and sets _cronGroupCollapsed = cronStored != "false". Under the bUnit Loose JS mock an unseeded read returns null → the Scheduled group stays collapsed, and the tests re-expanded it with a cron-group-toggle click. Because the localStorage read runs on an async continuation, it can fire after the toggle click and re-collapse the group (followed by StateHasChanged()), dropping the cron item from the group body and intermittently failing the Assert.Contains(...). The cronconv:-prefix sibling and the cron-API variant are exposed to the same race.

Fix

For the three cron-grouping tests:

• Seed localStorage.getItem("botnexus-cron-collapsed") → "false" (new ExpandScheduledGroupByDefault() helper, mirroring the established localStorage.getItem setup pattern in MainLayoutTests), so OnAfterRenderAsync lands on expanded deterministically and there is no re-collapse to race.
• Drop the brittle toggle click and assert inside cut.WaitForAssertion(...), which retries until the async render (including the cron→conversation-id HTTP load in the assigned-conversation test) has settled.
• ConversationAssignedToCronJob_RenderedInScheduledGroup no longer needs await Task.Delay(100); converted from async Task to void.

The behaviour under test is unchanged — the cron conversation must appear inside the Scheduled group. ScheduledGroup_CollapsedByDefault is intentionally left untouched (it relies on the default-collapsed state).

Verification

• dotnet build of the test project: 0 warnings, 0 errors.
• Hardened ConversationGroupingTests run 6× → 8/8 PASS each (was racing before).
• scripts/repo/test-impacted.ps1: All impacted tests passed — BlazorClient.Tests 606/606, plus Architecture.Tests + Scenarios.Tests safety nets.

Merge Notes

Standalone, test-only, single file (tests/.../ConversationGroupingTests.cs). No file overlap with the only other open PR (#1572, mobile ask_user). Safe to merge in any order; merging this turns main Build & Test green.