fix sidebar empty section behavior

[cynfria]

Category: fix
User Impact: Empty sidebar sections now behave consistently, and newly created projects remain immediately visible when their first chat opens.

Problem: The empty Chats header used different ordering and collapse behavior from its populated state, including a caret when there was nothing to collapse. Creating a project could also open its first chat without exposing the project in a previously collapsed Projects section.

Solution: Reuse the shared section-header treatment for empty Chats while making empty chat lists non-collapsible. Carry an explicit, window-local project-created revision to the session list so only local creation expands Projects, without treating ordinary backend list refreshes as creation.

File changes

src/app/AppShell.tsx
Records explicit local project creation and passes that signal into sidebar navigation while preserving the existing project-save workflow.

src/app/views/NavigationPanesView.tsx
Forwards the project-created revision to the session-list capability.

src/app/views/tests/NavigationPanesView.test.tsx
Covers the static empty Chats label and verifies that only explicit local project creation expands Projects.

src/features/sessions/capabilities/SessionListCapability.tsx
Responds to the explicit creation signal by opening Projects without inferring intent from project-list changes.

src/features/sessions/ui/session-list/SidebarProjectsSection.tsx
Replaces the bespoke empty Chats header with the shared non-interactive section header.

src/features/sessions/ui/session-list/SidebarRecentsSection.tsx
Keeps empty chat actions visible and removes collapse interaction when there are no chats.

src/features/sessions/ui/session-list/tests/SidebarRecentsSection.test.tsx
Adds regression coverage for the non-collapsible empty Chats state.

[morgmart]

🤖 Automated code review

REQUEST_CHANGES. The exact three-dot comparison was reviewed by static inspection at head e25465c. One blocking lifecycle bug remains in the core project-creation flow: a creation signal emitted while the session list is unmounted is treated as the component's baseline and discarded when the sidebar returns. The supplied GitHub evidence was inspected; Rust, DCO, clean-room install, and close checks passed, while Frontend checks and unit tests were still in progress at capture time. Required checks independently govern merge readiness.

Deterministic publication result: 1 blocking and 0 non-blocking finding(s) publishable; 0 duplicate(s) suppressed.

[cynfria]

🤖 The blocking lifecycle finding is fixed in 3d13769, with regression coverage for a pending creation signal received on mount. The review thread is resolved and all required checks pass. Please re-review the latest head.

[morgmart]

🤖 Automated code review

APPROVE. Fresh static inspection of the complete exact three-dot comparison at head 3d13769 found no publishable findings. The prior automated remount-lifecycle issue is fixed: AppShell now retains a nonzero pending creation revision while the session list is absent, SessionListCapability opens Projects when it mounts with that signal, and acknowledgement clears only the revision actually handled so a concurrent newer creation remains pending. Regression coverage exercises both ordinary project-list refreshes and initial mount with a pending creation signal. The empty Chats states use localized copy and shared design-system primitives, remain keyboard-accessible, expose no false disclosure control, and keep the start-chat action visible. Navigation/consent behavior, async and failure paths, lifecycle and race behavior, accessibility, localization, design-system rules, test honesty, and changed-flow coverage were rechecked. Supplied GitHub evidence was inspected; all listed check runs completed successfully, while the legacy combined commit status was pending with no status contexts. Required checks independently govern merge readiness.

Deterministic publication result: 0 blocking and 0 non-blocking finding(s) publishable; 0 duplicate(s) suppressed.

Pending checks: 1 check(s) are not complete.

This approval reflects the completed code review only; merge readiness remains governed by the repository's required checks.