Fix JSX elements closed directly before |] and }

[andreypopp]

Two lexing bugs where a JSX end tag directly touching a closing delimiter failed to parse:

let _ = [|<div>aa</div>|]     (* >|] lexed as the >| operator + ] *)
let _ = {x = <div>a</div>}    (* >} lexed as GREATERRBRACE (object-override closer) *)

Fixes

• Array literals: a dedicated >|] lexer rule backtracks to give the > back (closing the tag) and lets |] lex as BARRBRACKET. An operator like >| can never legally be followed by ] without parentheses, so no valid program changes meaning; 1>|2, [|1>|2|] and >|= are covered by tests. Same technique as the earlier removal of the >]/GREATERRBRACKET rule that made list literals work.
• Braced expressions: >} is stolen the same way, and both grammars now close object overrides with the two-token sequence GREATER RBRACE instead of GREATERRBRACE. {< x = 2 >} keeps parsing in both spacings (and {< x = 2 > } becomes newly accepted).

Both fixes are applied to the two parsers (mlx preprocessor and merlin reader), with cram tests including the merlin -conv bridge.

Known narrow regression

An override field ending in an unparenthesized comparison directly before the closer — {< x = 1 > 2 >} — now requires parentheses: {< x = (1 > 2) >} (pinned in tests). The parser shifts the final > as a comparison; stock OCaml's single-token >} avoided the ambiguity. Menhir picked up exactly one new silently-solved shift/reduce conflict from this; no reduce/reduce.

🤖 Generated with Claude Code

[andreypopp]

Formatter port: ocaml-mlx/ocamlformat-mlx#17. Note from testing over there: the override-comparison limitation is broader than the description above — an unparenthesized a > b in any override field position (not just directly before the closer) needs parentheses now, e.g. {< x = (1 > 2); y = 5 >}. The ocamlformat-mlx PR keeps such parentheses when printing.

[andreypopp]

Added a third fix to this PR (also ported to ocaml-mlx/ocamlformat-mlx#17): object types written without a space after < — e.g. (x : <m : int>) — now parse. <m lexes as a JSX open token, but a type context can never contain JSX, so the type grammar accepts the fused token as < + first method label. No lexer changes, no new menhir conflicts.