fix(bases): keep Task List groups collapsed on first render

[renatomen]

Problem

A Task List base view configured with Default collapsed state: Collapsed renders every group collapsed, but the first chevron click does the opposite of what you ask: the clicked group stays collapsed and every other group expands.

Root cause

The collapse default is seeded during render, then overwritten by a state snapshot captured before that render.

1. The first render() returns early because Bases has not delivered data yet (the !this.data?.data guard in src/bases/TaskListView.ts). collapsedGroups is still empty.

2. Data arrives and onDataUpdated() runs the debounced render wrapper in src/bases/BasesViewBase.ts:

   const savedState = this.getEphemeralState();    // collapsedGroups: []  — captured BEFORE render
   try { await this.render(); }                    // seeds every group key
   finally { this.setEphemeralState(savedState); } // writes [] back over the seed

3. That render seeds the collapse default through initializeCollapseStateForSnapshot and paints the DOM all-collapsed.

4. The finally replaces collapsedGroups with the stale empty array and does not re-render — so the DOM shows collapsed groups while the view's state says nothing is collapsed.

5. The wipe is permanent: re-seeding is gated on initializedPrimaryGroupKeys, which already holds every key, so initializeCollapseStateForSnapshot never seeds again.

6. handleGroupToggle then reads collapsedGroups.has(key) === false and collapses the clicked group. The re-render expands all the others.

Because the corruption needs the pre-render snapshot to be empty, this only bites on the first load of a view that has no previously saved collapse state — which is exactly the "starts collapsed" case.

Fix

Restore collapse state from ephemeral state only before the view has built its first grouping snapshot; afterwards the view's own sets are authoritative.

hasInitializedCollapseState() and restoreCollapsedStateFromEphemeral() are extracted so the new guard is visible in review — the moved block is otherwise unchanged.

Tests

Two regression tests in tests/unit/ui/TaskListView.groupCollapse.test.ts replay the ordering the render wrapper actually produces (seed, then restore a pre-render snapshot): one asserts the collapse default survives it, one asserts a toggle then expands only the clicked group.

The suite already covered the opposite, safe ordering (restore-then-seed). The ordering production actually produces was untested, which is how this went unnoticed.

Verification

• Both new tests fail on main without the fix — with exactly the reported symptom — and pass with it.
• Full suite green on Node 20 / TZ=UTC.
• tsc --noEmit and eslint clean.
• Manually verified in a vault with a full Obsidian restart: a chevron click now expands that group and leaves the others collapsed.

Known trade-off

If setEphemeralState is ever called after the view's first render with collapse state worth applying, that portion is now ignored. The only caller I could find that runs post-render is the render wrapper's own save/restore round trip, which is the one we want ignored — but flagging it in case there is a path I missed.

Note on the broader design

The underlying coupling remains: get/setEphemeralState serves both Obsidian's cross-reload persistence and an intra-render scroll round trip, so correctness depends on call ordering relative to render(). Separating those concerns in BasesViewBase would eliminate the whole class of bug, but it touches KanbanView and CalendarView, which are not affected today. I kept it out of this change so the fix stays small and reviewable — happy to follow up if you would prefer that direction.