feat(chat-scrolling): Add visual navigation markers for quick access …

[entitycs]

…to user message within chat windows.

• Introduces a new chatUserScrollMarker.js module that renders clickable indicators along the scrollbar gutter representing each USER message in current sessions. The component uses absolute positioning and event listeners so you can tap any marker to view the associated message instantly (no scroll needed).

I often find myself needing to find code I've pasted or questions I've asked in previous chats - either to find my place, ask them again, or feed them to a different model. This makes finding such artifacts much easier.

I chose marking user messages over marking assistant responses. This is because user messages are often shorter and (imo) better for re-aligning oneself within a conversation that has either gone stale or one that is relatively long-winded.

Note: Proposed Changes:
• This commit introduces a root level js file. Proposal would be to refactor chatRenderer.js, and eventually place this file into /static/js/chat/render/userMessageScrollMarker.js; or to use some similar structure / convention down the road.

Summary

Created to assist with ease of use and accessibility. Modifies style.css, and the minimal additions to render as a standalone module (sw.js, index.html). Adds new 'scroll-marker-track' element overlaying chat-container content area. Scroll track contains per-user-message markers styled as thin vertical lines or pills. Respects theme colors via CSS custom properties for consistent styling across themes. The module includes ResizeObserver and MutationObserver handlers to adapt layout changes, along with window resizes.

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

Closes #3878

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. Build, open, and run app; eg., via docker compose up -d --build and navigating to the app eg., http://localhost:7000
2. Open or create any chat conversation long enough to produce a scrollbar, and which contains at least one user message.
3. Assure the user message is visible while the scrollbar handle overlaps each marker. Assure no markers are missing.
4. Assure markers stay aligned through UI changes such as pinning windows left/right/top relative to the chat window, resizing the chat window, deleting of chat messages (results in markers being removed, re-drawn, re-aligned), etc.
5. Assure clicking on a marker navigates you properly to the associated user message.

*These are all tests that I've carried out on the following browsers on Windows (latest as of posting): Brave, Chrome, Edge, Comet, Zen. Untested: Firefox, et.al.

Note that the accuracy of alignment varies some per browser, but please report if you experience a noticeable misalignment. I am unaware of any reliable way to measure each browser's implementation of scrollbar arrows and scrollbar handle sizing without using some generic formulas / average values.

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