fix(factsheets): route the mode home through the shared composer template

[BigSimmo]

Summary

• The Patient Factsheets mode home (/factsheets) hand-rolled its own <main>/composer-slot markup instead of reusing ModeHomeMain + ModeHomeTemplate (the pair every other standalone mode home — DSM, Services, Forms, Specifiers, Formulation, Calculators — already uses). Its bespoke slot never applied the SSR data-composer-reserve attribute those templates set, so instead of the in-flow hero composer, the page fell back to the phone bottom dock (the search bar pinned to the viewport bottom with a +/send-arrow, and a blank gap where the composer should have been).
• Converted src/components/factsheets/factsheets-home-page.tsx to render through ModeHomeMain + ModeHomeTemplate, matching the minimal shape the universal Answer home (/) uses: hero icon/title/subtitle, the shared in-flow composer, the privacy note, and a governance-disclaimer footer. Only the title, subtitle, icon, and search routing (/factsheets/search) differ from mode to mode — the page itself is now the same shared template.
• Removed the page's previous bespoke "Browse by topic" category-chip grid and "Start with a factsheet" card grid. Confirmed this is not a functional regression: /factsheets/search already lists every factsheet when no query is submitted and already has its own category-filter UI, so both are still fully reachable — they're just no longer duplicated as a home-page preview.
• Removed featuredFactsheets(), categoryCount(), and factsheetCategoryGlyph() (plus their now-unused imports/backing maps) from factsheets-data.ts/factsheets-icons.ts — each was used only by the removed home-page markup and had no other caller or test coverage.
• Added a regression-guard test to tests/mode-home-loading-contract.test.ts asserting factsheets-home-page.tsx imports/renders ModeHomeTemplate and no longer references DesktopComposerPortalSlot directly, so a future edit can't silently reintroduce a hand-rolled composer host.

Verification

• npm run verify:pr-local — all 10 selected checks passed: check:runtime, check:installed-lock-parity, format:changed, lint, typecheck, test (649 files / 6999 passed, 4 skipped), build, check:rag:fixtures (36 golden cases, 25 suites), check:medication-interactions, check:medication-lexicon-report. Summary line: PR-local verification summary: - completed: check:runtime, check:installed-lock-parity, format:changed, lint, typecheck, test, build, check:rag:fixtures, check:medication-interactions, check:medication-lexicon-report - failed: (none) - not reached: (none).
• npm run verify:ui when UI, routing, styling, browser behavior, reduced-motion, or forced-colors behavior changed — not run as the full Chromium gate; instead verified directly with a live Playwright screenshot check at 390×844 against the local dev server (npm run ensure): confirmed /factsheets now renders the composer in-flow under the hero (composer-slot host has 1 child, height 106px, data-composer-reserve cleared, zero bottom-dock elements present) and structurally matches /dsm and / (Answer) at the same viewport, with no console/page errors on /factsheets or /factsheets/search.
• npm run verify:release before release or handoff confidence claims — not run; this is a PR handoff, not a release, and the change carries no provider-backed surface.

This PR does not touch retrieval, ranking, selection, chunking, source/citation rendering, or answer-contract behaviour, so eval:retrieval:quality / eval:rag / eval:quality are not applicable.

Risk and rollout

• Risk: Low. UI-only change confined to one mode-home page component and its two small data/icon modules; scripts/pr-policy.mjs classifies the changed paths as UI, not clinical-risk (no auth/privacy/patient/upload paths touched) and not a RAG-ranking surface.
• Rollback: Revert this commit; no data, schema, or config changes are involved.
• Provider or production effects: None.

Notes

• This does not touch src/lib/rag/**, clinical-search, retrieval-selection, ranking-config, answer-ranking, the eval harness, or the golden fixture, so no RAG impact: declaration applies.
• The Clinical Governance Preflight section is intentionally omitted: this change doesn't touch ingestion, answer generation, search/ranking, source rendering, document access, privacy, production env, or clinical output — it only changes which shared layout component renders a static demo-content mode home.

---

Generated by Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[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]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in:49 minutes

Limit details: You’ve used all 1 included review currently available under your plan. You completed 101 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour.

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

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

Run ID: de9f88c0-2570-426d-969d-eb5f9b881693

📥 Commits

Reviewing files that changed from the base of the PR and between dda4956 and dd4786c.

📒 Files selected for processing (5)

• docs/branch-review-records/b56ee4be00d225db51c54f2debc8c43e4fe2b0123f4aaf6c647811c847b94790.record.md
• src/components/factsheets/factsheets-data.ts
• src/components/factsheets/factsheets-home-page.tsx
• src/components/factsheets/factsheets-icons.ts
• tests/mode-home-loading-contract.test.ts

---

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