diagram: equation-error reasons stop at the FFI, so the app shows only the error code #1030

The engine now carries a human-readable reason on every equation diagnostic it
can (EquationError::details, compiler-unification Phase 5b), and that reason
reaches the libsimlin FFI as SimlinErrorDetail::details. The web app throws it
away: an equation error still renders as the bare error code, while a unit error
on the same variable renders its sentence.

Where it is dropped:

• src/diagram/project-controller.ts:285 builds the core EquationError from
  {code, startOffset, endOffset} only. The unit-error arm three lines above it
  (details: err.details ?? undefined) keeps the reason.
• src/core/datamodel.ts:52 -- interface EquationError has no details
  field, so there is nowhere to put it. UnitError (same file) has one.
• src/diagram/VariableDetails.tsx:552 renders
  error: {errorCodeDescription(error.code)}. The unit arm at line 523 renders
  {error.details ?? errorCodeDescription(error.code)}.

So a modeler who writes 1 + nowhere_var sees unknown_dependency in the app,
where the CLI and the MCP servers say 'nowhere_var' is not a variable of model 'main'.

Fix shape (~15 lines, mirroring what the unit path already does):

1. Add readonly details: string | undefined to EquationError in
   src/core/datamodel.ts.
2. Pass details: err.details ?? undefined in the equation arm of
   src/diagram/project-controller.ts.
3. Render {error.details ?? errorCodeDescription(error.code)} in
   src/diagram/VariableDetails.tsx, as the unit arm does.
4. Extend the variable-details-display test to cover an equation error that
   carries a reason and one that does not (a parse error writes no reason: its
   reason is the source snippet).

Follow-up to the compiler-unification Phase 5b commit
(engine: diagnostics keep their message from parse to collection), which
established the channel on the Rust side and left this boundary as the one
surface where an equation reason stops.