[MC-460-A] fix(frontend): scroll active concept into view in Compare/Tags too

[TrueNorth49]

MC Task: MC-460 — Concept menu auto-scroll only works on Annotate / Lane MC-460-A

Summary

The concept-menu auto-scroll (keep the selected entry in view) was intended to work in every mode, but only fired on the Annotate page.

Root cause

The scroll effect in ParseUI.tsx depended solely on selectedRealizationKey:

useEffect(() => {
  if (!selectedRealizationKey) return;   // bails when null
  // …scroll the [data-realization-key] chip into view
}, [selectedRealizationKey]);

• Annotate navigates by realization (goToRealizationOffset), which sets selectedRealizationKey → effect fires → menu scrolls. ✅
• Compare / Tags navigate by concept (goToConceptOffset), which explicitly does setSelectedRealizationKey(null) and only updates conceptId. The effect bailed at the null guard, so the menu never followed the selection. ❌

The effect itself was already global and the sidebar (ConceptSidebar) is shared across all modes — the trigger was just realization-specific, a value only Annotate produces.

Fix

When no realization is selected, fall back to scrolling the active concept's parent row ([data-testid="concept-parent-button-${conceptId}"], already rendered by ConceptSidebar), and add conceptId to the dependency array so concept-level navigation also triggers the scroll.

Testing

• Added a regression test: in Compare mode, ArrowDown between concepts scrolls the active concept's parent row into view (asserts scrollIntoView is called on concept-parent-button-3).
• npx vitest run src/ParseUI.test.tsx — 138 passed / 7 skipped
• npx tsc --noEmit — clean
• npm run build — green

🤖 Generated with Claude Code

[TrueNorth49]

Self-review — [MC-460-A]

Overview: Generalizes the sidebar auto-scroll so it follows the active concept in Compare/Tags, not just realization pills in Annotate. Single effect change + regression test.

Correctness ✅

• concept-parent-button-${concept.id} is rendered for every concept row in ConceptSidebar, so the fallback selector always resolves to a real element.
• Branch logic is sound: realization key present → scroll the pill (Annotate, unchanged); absent → scroll the active concept row (Compare/Tags). conceptId added to deps so concept-level navigation re-fires the effect.
• conceptId is a numeric state (useState(1)), so interpolating it into the selector string is injection-safe.
• typeof … === 'function' guard retained for jsdom/no-scroll environments.

Notes / minor

• Behavior change on mount and on Annotate concept-level fallback: the effect now also scrolls when selectedRealizationKey is null (previously a no-op). { block: 'nearest' } makes this a no-op when the row is already visible, so it's harmless and actually more consistent.
• Tags mode benefits on click selection; arrow keys still return early before concept navigation in Tags (pre-existing, out of scope).

Tests ✅

• Added Compare-mode regression test asserting scrollIntoView fires on concept-parent-button-3 after ArrowDown. Mutates Element.prototype.scrollIntoView and restores in finally.
• vitest src/ParseUI.test.tsx 138 passed / 7 skipped · tsc --noEmit clean · npm run build green.

No blockers.