fix(ui): stop scroll bounce when collapsing chrome pins at the bottom

[BigSimmo]

Summary

• Fixes the choppiness/bounce felt when scrolling to the bottom on phones (reported across most/all screens).
• Root cause: the phone hide-on-scroll chrome (header/composer) collapses in-flow, above the #main-content scroll container. Hiding it grows the container and shrinks its max scroll offset (~72px). At the bottom the browser clamps scrollTop to that shrinking maximum, emitting a phantom "up" reading on each frame of the ~240ms collapse animation.
• The previous bottom-clamp guard in computeScrollHideUpdate only held the hidden state when the prior offset sat more than minimumDelta above the new maximum — a predicate the browser's per-frame clamping makes unreliable. On the frames it missed, the phantom "up" revealed the chrome, which grew the viewport back and re-hid on the next down-scroll → a self-sustaining hide/reveal bounce.
• Fix: generalise the guard — while the chrome is hidden and the offset is pinned to the bottom edge and moving up, treat it as layout feedback: hold the hidden state and rebase intent. Only a genuine upward scroll that pulls the offset clear of the bottom reveals. This holds across the entire multi-frame collapse, so the bottom stays stable and all content remains reachable.
• Affected area: src/components/clinical-dashboard/use-hide-on-scroll.ts (generalised bottom-clamp guard + bottomClampTolerance), tests/use-hide-on-scroll.test.ts (deterministic multi-frame-collapse and bottom-overscroll tests).

Verification

• Unit: vitest run tests/use-hide-on-scroll.test.ts — 12 passed (9 existing + 3 new: multi-frame collapse clamp, small-shrink phantom, bottom rubber-band overscroll).
• Ran the ui-smoke hide-on-scroll / header / dock / composer Playwright specs against the running dev server with the preinstalled Chromium — 10 passed, including non-answer phone header keeps the in-flow collapse hide, phone long answer stays scrollable and clear of the composer dock, and answer glass header overlays main and fully hides while scrolling on phones.
• Full unit suite: 2669 passed; the only failure is one .dom.test.tsx that needs jsdom (missing in this container), unrelated to this change. Lint clean; no new typecheck errors (pre-existing test-dep errors unchanged: 51 before and after).
• Behavioural repro on a phone viewport (390×780) with the preinstalled Chromium: chrome hides on down-scroll, reveals on up-scroll, and at the bottom the state no longer flips (0 hidden-state flips, scrollTop locked at the bottom); the last content element is fully visible (0px overflow).
• Verification not run: npm run verify:pr-local — this container is missing dev test deps (jsdom, @testing-library/react, @axe-core/playwright) and the managed Playwright browser build, so the packaged gate cannot run end-to-end here; the equivalent checks were run directly (above).
• UI verification not run: npm run verify:ui gate — same managed-Chromium gap; substituted with the equivalent ui-smoke Chromium specs above (10 passed).

Risk and rollout

• Risk: low; the change is confined to one pure decision function (computeScrollHideUpdate) shared by all hide-on-scroll hosts, fully covered by unit tests and consistent with the existing bottom-clamp test.
• Rollback: revert this branch's commits to use-hide-on-scroll.ts; no data, schema, migration, or configuration change is involved.
• Provider or production effects: None.

Clinical Governance Preflight

This is a client-side scroll-interaction fix, flagged clinical-risk only because the file path is under src/components/clinical-dashboard/ (the policy's path heuristic). It does not touch ingestion, answer generation, search/ranking, source rendering, document access, privacy, Supabase, or clinical output, so each item below holds unchanged.

• Source-backed claims still require linked source verification before clinical use
• No patient-identifiable document workflow was introduced or expanded without explicit governance approval
• Supabase target remains Clinical KB Database (sjrfecxgysukkwxsowpy)
• Service-role keys and private document access remain server-only
• Demo/synthetic content remains clearly separated from real clinical sources
• Source metadata, review status, and outdated/unknown-source behavior remain conservative
• Deployment classification/TGA SaMD impact was checked when clinical decision-support behavior changed

Notes

• Behaviour preserved: reveal near (but not glued to) the bottom still works; scrolling to the top always restores the chrome, including on very short pages.
• The bottom-edge tolerance is deliberately one-sided so iOS bottom rubber-band overscroll holds the chrome hidden instead of flickering it; a regression test locks this in.

---

Generated by Claude Code

[coderabbitai]

Warning

Review limit reached

@BigSimmo, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 24 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 93b5d956-e43d-43d5-9a7a-4283b75e7fcf

📥 Commits

Reviewing files that changed from the base of the PR and between bdeb925 and 46da560.

📒 Files selected for processing (2)

• src/components/clinical-dashboard/use-hide-on-scroll.ts
• tests/use-hide-on-scroll.test.ts

📝 Walkthrough

Walkthrough

Updates scroll-hide behavior to recognize near-bottom upward offsets as layout clamping, preserving hidden chrome during collapse and revealing it after a genuine upward scroll. Adds tests for multi-frame and single-frame clamp scenarios.

Changes

Scroll clamp handling

Layer / File(s)	Summary
Bottom-clamp detection and validation src/components/clinical-dashboard/use-hide-on-scroll.ts, tests/use-hide-on-scroll.test.ts	Adds a bottom clamp tolerance, treats near-bottom upward offsets as layout feedback while hidden, and tests sequential clamp frames plus phantom clamp behavior.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• BigSimmo/Database#578: Both modify the clinical dashboard scroll-hide hook and its internal hidden/offset state handling.
• BigSimmo/Database#703: Both update computeScrollHideUpdate and tests for bottom scroll intent and hide/reveal timing.
• BigSimmo/Database#704: Both modify bottom pinned/clamp handling in computeScrollHideUpdate and related test expectations.

Suggested reviewers: cursoragent

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly reflects the main fix: preventing bottom-edge scroll bounce in the hide-on-scroll UI.
Description check	✅ Passed	The description matches the template well, with Summary, Verification, Risk and rollout, Clinical Governance, and Notes filled in.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/scroll-choppiness-bouncing-ayxqd6

---

_{Comment @coderabbitai help to get the list of available commands.}

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/components/clinical-dashboard/use-hide-on-scroll.ts`:
- Around line 72-86: Update the bottom-clamp condition in the currentlyHidden
scroll-handling branch so it treats an offset as pinned only when its distance
from maxOffset is within bottomClampTolerance on either side, rather than
accepting every offset above maxOffset minus the tolerance. Preserve the
hidden-state rebasing behavior for genuinely bottom-adjacent offsets.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 3c71badc-2c93-43f9-9da8-43e7853d5814

📥 Commits

Reviewing files that changed from the base of the PR and between bf9534c and bdeb925.

📒 Files selected for processing (2)

• src/components/clinical-dashboard/use-hide-on-scroll.ts
• tests/use-hide-on-scroll.test.ts