feat(ui): added grouping chat sessions into ui

[54x1]

Summary

Added a database-backed project system that lets users organize chat sessions into named project groups. Introduces a new Project SQLAlchemy model with owner-scoped isolation, kebab-case slug generation, and idempotent migration logic. A new routes/project_routes.py module exposes full REST API endpoints: list, create, update, delete, session assignment/removal, and project detail lookups that return associated sessions. The project router is registered in app.py and the migration runs on startup.

Target branch

• This PR targets dev, not main. All PRs land in dev; main is curated by the maintainer at each release. If your PR is on main by accident, click "Edit" on this PR and change the base.

Linked Issue

Fixes #5265

Type of Change

• Bug fix (non-breaking — fixes a confirmed issue)
• New feature (non-breaking — adds new behaviour)
• Breaking change (changes or removes existing behaviour)
• Refactor / cleanup (behaviour unchanged)
• Documentation only
• CI / tooling / configuration

Checklist

• I searched open issues and open PRs — this is not a duplicate.
• This PR targets dev
• My changes are limited to the scope described above — no unrelated refactors or whitespace changes mixed in.
• I actually ran the app (docker compose up or uvicorn app:app) and verified the change works end-to-end. Type-checks and unit tests are not enough.

How to Test

1. Start the app (docker compose up or uvicorn app:app:app).
2. Send GET /api/projects/ — should return an empty [] on a fresh database.
3. Send POST /api/projects/ with body {"name": "My App", "description": "Testing"} — should return a project object with an id, name, and a kebab-case slug ("my-app").
4. Send GET /api/projects/ — should now include the newly created project.
5. Send PATCH /api/projects/<id> with {"name": "Renamed App"} — verify the project name updated.
6. Send POST /api/projects/<id>/assign with {"session_id": "<some-session-id>"} — verify the session is now linked to the project.
7. Send GET /api/projects/<id> — verify session_count increased and the session appears in the sessions list.
8. Send POST /api/projects/<id>/assign with {"session_id": "<some-session-id>", "project_id": null} — verify the session is removed from the project.
9. Send DELETE /api/projects/<id> — verify the project is deleted.
10. Send GET /api/projects/ — verify the deleted project no longer appears.

WebUI
Click arrow and add to new folder

Visual / UI changes — REQUIRED if you touched anything that renders

Anything that changes what the UI looks like — buttons, icons, padding, colors, fonts, spacing, layout, CSS, HTML, SVG, or any static/js/ module that draws to the DOM — needs all of the following. PRs that change rendering without these WILL be closed.

• Screenshot or short clip of the change in the running app, attached below. Mobile screenshot too if the change affects mobile.
• Style match: the change uses Odysseus's existing visual language. Specifically:
  • Reuse existing CSS variables (--red, --fg, --bg, --card, --border, etc.) — do not introduce new color values, font sizes, or spacing units.
  • Reuse existing button/input/card/border classes. Don't invent parallel styling.
  • No Unicode emoji in UI or code. Use inline SVG (matching the monochrome icon style already in static/index.html) or plain text.
  • Monospaced font (Fira Code) for primary UI text. Don't override.
  • Dark theme is the default; any light-mode work must be wired through the existing theme system, not hard-coded.
• No new component patterns. If a similar widget already exists in the app, extend it instead of writing a parallel one.
• I am not an LLM agent submitting a bulk PR. If you are, please open an issue describing the problem first — bulk auto-generated PRs that don't match the project's visual style are closed on sight, even when the underlying fix is correct.

Screenshots / clips

[54x1]

[Ninthkitten]

Sharing a complementary piece from a self-hosted install, in case it is useful for this work.

We run a locally patched folder model where the backend enforces the folder boundary, not just the sidebar:

• list_sessions, send_to_session and manage_session are scoped to the calling chat's folder
• chat search is filtered the same way
• a chat in folder X sees and reaches only folder X; unfiled chats see only unfiled
• a wrong-folder id answers "not found" — the same shape as the existing ownership wall, so a room's existence is not disclosed from outside it
• the four tool descriptions state the boundary, so the model does not attempt cross-folder calls and then explain failures it cannot see the cause of

Five files: src/agent_tools/session_tools.py (a get_session_folder helper plus filters), src/tools/search.py, src/tool_execution.py (session id plumbed to search), src/tool_schemas.py (descriptions).

The motivation was a user requirement phrased as: chats in a folder see chats in that folder — folders as actual rooms rather than a visual grouping. Without backend scoping, agent tools still reach every session regardless of what the sidebar shows, so the separation holds visually but not functionally.

Happy to open this as a PR against this branch if the direction is welcome — or to leave it here as a note if folder semantics are meant to stay presentation-only.