Prevent learner dashboard metric help text from overflowing mobile viewport

Problem

The integrated accessibility registry reaches 29/30 states, then fails the real signed-in learner dashboard at the 390px viewport. span#enrolled-definition.metric-help-text is centered on its trigger with a max-content width; its right edge reaches approximately x=413 and increases document width by 23 CSS pixels.

This is a real responsive defect on /courses/<family>/<cohort>/dashboard, not a registry exception. The help content must remain available and the overflow assertion must remain strict.

Authority

• _docs/design/design-system.md — the dashboard is an ordinary content page using the shared narrow shell, design tokens, theme behavior, and visible focus treatment.
• _docs/specs/04-courses-and-cohorts.md — learner dashboard/cohort route ownership.
• _docs/specs/10-verification-strategy.md — accessibility, keyboard, zoom/reflow, responsive browser, and maintained-gate requirements.
• _docs/PROCESS.md — template work requires desktop/mobile screenshots and the full applicable browser tier.

Scope

• Repair the metric-help-text geometry in courses/templates/courses/dashboard.html so the enrolled-definition tooltip cannot enlarge or leave the viewport at narrow widths.
• Cover both dashboard branches that render the metric row: before the first homework is scored (two tiles) and after scoring begins (four tiles).
• Preserve the tooltip's text, aria-describedby relationship, tooltip semantics, keyboard focus behavior, and dark/light token usage.
• Add focused browser regression coverage for document and tooltip bounds at 390px and 320px, including the tooltip-hidden and keyboard-visible states.
• Retain the established desktop metric presentation and ordinary narrow dashboard shell.

Non-goals

• Redesigning the learner dashboard, changing metrics/count calculations or copy, or changing dashboard routes/authentication.
• Changing /courses catalogue/card target sizes addressed by #417.
• Hiding or truncating the definition, removing the help control, disabling focus, or using global overflow-x: hidden/clipping to conceal the defect.
• Weakening, skipping, quarantining, or adding an exception for learner.dashboard in the accessibility registry.
• Broad changes to shared cards, stat tiles, or other public pages unless a narrowly demonstrated shared primitive defect requires them and regression coverage is added.

Dependencies and blocked work

• No open implementation dependency. #426 exposed this defect by repairing the integrated accessibility harness; it is historical/test-baseline context, not an interface prerequisite for the CSS repair.
• This issue blocks completion evidence for #426 and full browser evidence for template candidates such as #420/#425. After this fix lands, those candidates must rebase/freeze and rerun their graph-selected gates; prior selective evidence does not waive the failing registry state.

Acceptance criteria

• At 390×844 and 320×800, document.documentElement.scrollWidth and document.body.scrollWidth are no more than one CSS pixel wider than the viewport before, during, and after keyboard exposure of the enrolled definition.
• When visible, #enrolled-definition stays fully inside the viewport/content gutter (left >= 0, right <= viewport width, allowing the same one-pixel rounding tolerance), wraps into readable lines, and is neither clipped, truncated, nor horizontally scrollable.
• The pre-score two-tile state and scored four-tile state both satisfy the narrow-width contract with representative short and large metric values.
• The ? control remains a native keyboard-focusable button with a visible focus indicator; Tab focus reveals the definition, and moving focus away hides it without trapping focus.
• The definition remains associated through aria-describedby="enrolled-definition", has one unique ID in the rendered branch, retains role="tooltip", and keeps the existing truthful copy.
• With JavaScript disabled, the server-rendered dashboard and CSS-only focus/hover disclosure remain usable and within bounds; no script is required to read the definition.
• Light and dark themes pass at 390px and 320px with legible definition text/border/focus treatment and no horizontal overflow.
• At 768px and 1440×900, the metric row remains aligned, the tooltip is readable and visually anchored to its control, and the dashboard remains on the ordinary narrow content shell.
• No global overflow suppression, registry exception, test skip/quarantine, content hiding, or unrelated dashboard redesign is introduced.
• Focused Django dashboard tests, the focused browser regression, and the complete integrated accessibility registry pass; the graph-selected full Playwright tier also passes.

Browser scenarios

1. Sign in as the deterministic learner and open a cohort dashboard before the first homework is scored. At 390×844 and 320×800 in light and dark themes, record page width, Tab to “What enrolled means,” assert the tooltip is visible and in bounds, Tab away, and assert the page never overflows.
2. Repeat for the scored dashboard containing all four headline metric tiles, including representative large values that exercise wrapping/alignment.
3. Repeat the mobile focus scenario in a JavaScript-disabled context; the definition remains accessible through CSS focus behavior and the server page remains complete.
4. At 768px and 1440×900, inspect the metric row and focused tooltip in both themes for alignment, anchoring, focus visibility, and absence of regression.
5. Run the complete accessibility registry and verify learner.dashboard passes with its original strict structure/overflow checks and no exception.

The independent tester stores and inspects light/dark screenshots for the focused tooltip at 1440, 768, 390, and 320 under .tmp/screenshots/, and confirms they show the intended authenticated dashboard rather than an error/debug/login page. Screenshots and logs must contain only synthetic user data.

Start in courses/templates/courses/dashboard.html and reproduce the learner.dashboard registry failure at 390px and 320px in both pre-score and scored dashboard branches. Run the focused Django dashboard tests and browser regression, including keyboard-visible, JavaScript-disabled, and theme scenarios. Done means the tooltip remains readable, associated, focusable, and fully in bounds without weakening the strict overflow or accessibility checks.