[BUG FIX] [MER-5776] Fix authoring UI and fraction choice labels

[darrensiegel]

This PR fixes a couple of issues found during the "Math Expression Playtest" session last week.

1. The "Number with Units" option was using the wrong input type, which made it impossible to enter values that actually contain units.
2. The "Fraction" input type was using incorrect labels for the "match exactly / equivalent" options, which led to misleading results.

[github-actions]

	Warnings
⚠️	PR is large (955 LOC changed). Consider splitting.

Risk score: 5 → risk/medium

Generated by 🚫 dangerJS against e28f62d

[github-actions]

AI Review — elixir

No issues found

[github-actions]

AI Review — performance

Authored numeric inputs are parsed twice

file: gleam/src/math/match/evaluate.gleam
line: 671
Description: Each operand is first parsed by parse_quantity_or_expression, then parsed again by parse_scalar or submitted_numeric_value_source. This duplicates lexer/parser work on a potentially hot submission-evaluation path.
Suggestion: Extract the numeric value from the initial parsed result and pass it into scalar/quantity normalization, avoiding the second parse.

[github-actions]

AI Review — security

No issues found

[github-actions]

AI Review — ui

Fixed width breaks mobile reflow

file: assets/src/components/activities/short_answer/sections/NumericInput.tsx
line: 185
Description: The 400px inline width can overflow at 320px viewport width, making the range-boundary control difficult to access when zoomed or on mobile.
Suggestion: Replace the fixed width with responsive styling, such as width: '100%' plus a desktop maxWidth, preferably through an existing CSS utility or component class.

Range inputs lack persistent visible labels

file: assets/src/components/activities/short_answer/sections/NumericInput.tsx
line: 167
Description: “Lower bound” is supplied only as placeholder and an accessible name. Once a value is entered, sighted users lose the persistent indication of what the field represents; the upper-bound field has the same issue.
Suggestion: Add visible <label> elements for both bounds and associate them with stable input IDs exposed by MathExpressionInput.

[github-actions]

AI Review — typescript

Label misrepresents exact matching

file: assets/src/components/activities/short_answer/sections/InputEntry.tsx
line: 697
Description: The exact mode matches the authored fraction exactly; it does not inherently require that fraction to be simplified. The new label can cause authors to select behavior that does not enforce what it promises.
Suggestion: Restore “Match this answer exactly,” or add validation/normalization that requires the authored and submitted fractions to be simplified.

[github-actions]

AI Review — gleam

Mixed-unit ranges use incomparable raw magnitudes

file: gleam/src/math/match/evaluate.gleam
line: 774
Description: Wrong/missing-unit matching now uses raw_spec. For ranges whose authored operands use different convertible units, their unconverted magnitudes are not comparable, producing incorrect matches.
Suggestion: Build the targeting spec in one consistent unit scale, or reject range operands that cannot share a single authored scale.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f544f8a6d6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[andersweinstein]

[From a local codex review:]

Parser-valid quantities can be graded using the wrong value.
   gleam/src/math/match/evaluate.gleam:724 ignores the parsed value AST and reparses the substring before the first space. I reproduced that an authored answer of 1 + 2 m marks 1 m correct and 3 m incorrect. The evaluator should extract a scalar literal from the AST or reject non-scalar expressions. This should have a regression test.
   
 However, as this is not a new issue with this PR, it will be captured in a follow-on ticket.