feat(nav): pin the assistant above the workspace order

[bobleer]

Summary

The sessions section rendered assistants and project workspaces from one ordering list, so the assistant (e.g. 小芳) could sit between projects and took part in drag reordering. Assistants are a product-level identity rather than one workspace among many, so they are now pinned above the workspace list and stay out of the workspace order.

• Assistant groups render pinned above the project workspace list in the sessions section.
• Pinned rows are not draggable and never become drop targets; a project drag now rewrites project positions only (reorderOpenedWorkspacesInSection('projects', …)), so the assistant's stored slot is never touched.
• The flat session view keeps the same shape: pinned assistant rows above the aggregate project session list.
• A hidden, deleted, or never-created assistant has no opened workspace, so the pin simply disappears without leaving an empty slot, and the workspace list is untouched. Reopening the assistant (Profile → assistants, or the assistant scene, which reopens closed assistants through setActiveWorkspace) brings the pin back automatically.

Type: bug fix / UI-UX

Areas: web UI (navigation sidebar), E2E navigation spec.

Motivation / Impact

The assistant is a single, always-reachable identity; project workspaces are an ordered, user-managed list. Mixing both in one sortable list let the assistant drift whenever the user reordered projects, and a project could even be dropped above it. After this change the assistant is always the first entry of the sessions section, and project ordering behaves exactly as before.

No data migration: persisted workspace order is still read as-is. Only rendering and the drag target section change.

Verification

CI (this PR, head 6fb4f0045):

• Frontend Build — passed (repository hygiene, i18n audits, theme audits, lint:web, pnpm --dir src/web-ui run test:run, build:web, mobile web checks).
• Rust / CLI Validation — passed after re-running a Windows job that timed out inside the Computer Use clipboard contracts step; the same step and the rest of the job passed on the re-run.
• Shell Deploy Scripts, Repository Object Sizes, Build Impact — passed.

Local:

• pnpm --dir src/web-ui exec vitest run src/app/components/NavPanel — new WorkspaceListSection cases pass; the only failures are 4 pre-existing cases in this host environment where Node 26 exposes a global localStorage that shadows jsdom (localStorage.clear() throws). The same failures reproduce on an unmodified main checkout, and the same suites pass on CI.
• pnpm --dir src/web-ui exec tsc --noEmit -p tsconfig.json — passed.
• pnpm run lint:web, pnpm run check:repo-hygiene, pnpm run theme:visual-contract, pnpm run verify:webkit-compatibility:test, pnpm run build:web — passed.
• npx tsc --noEmit in tests/e2e — passed.

Test coverage added in WorkspaceListSection.test.tsx: pinned above projects with a reversed stored order, assistant excluded from the drag group while projects stay draggable, pin above the flat list, no pin and no placeholder when the assistant is absent or hidden (grouped and flat), and the empty state. tests/e2e/specs/l0-navigation.spec.ts now includes the pinned row in the group-spacing selector so the pin-to-first-workspace gap stays covered.

Reviewer Notes

• Behavior change: assistants keep their persisted opened order inside the pin but are no longer drag-reorderable, because the workspace drag order no longer includes them. Nothing else in navigation depended on the assistant's index in that list.
• Dropping a dragged project directly on the pinned assistant is rejected (no drop target), which is the honest signal for "the assistant is not part of this order"; the surrounding project rows keep their drop lines.
• Remote scenarios: not affected. Controller-side navigation rendering only; no protocol, capability, or persisted-shape change.
• Appearance: no new data-openbitfun-part values; the pin keeps the existing item part plus a data-session-group-pinned hook.

Generated with OpenBitFun