Reduction/visualization endpoints: structured 400 on unparsable input (closes #355)

[wrigjl]

Closes #355.

Summary

Mis-shaped input on the reduction and visualization endpoints currently throws
into an HTTP 500 with a stack trace — any client (the GUI, curl, an LLM/MCP
client) gets opaque output with no actionable signal, and every bad request
writes a full stack trace to the server log.

This makes all five affected endpoints — mapSolution, reduce, gadgets,
visualizeReduction, visualize — surface parse failures as a structured
HTTP 400, matching the existing instance_parse_error /
certificate_parse_error pattern already used by solve/verify/problemInstance.

Changes

Reduction input exception + /mapSolution (original scope)

• Add ReductionInputException to Interfaces/ParseExceptions.cs (carries the
  IReduction, the received string, and the expected-format hint chosen at the
  throw site, so one type covers both instance-side and certificate-side parse
  failures).
• SipserReduceToSAT3 validates its source instance and certificate, throwing
  ReductionInputException with the CLIQUE instanceFormat/certificateFormat
  plus a Sipser-node-format addendum.
• SipserReduceToCliqueStandard.mapSolutions validates the : separator before
  indexing, throwing ReductionInputException naming 3SAT's certificateFormat.
  This replaces the IndexOutOfRangeException at the original crash site.

Extend to the remaining endpoints (#355)

• Add three shared helpers on ProblemProvider:
  • Unwrap — normalizes TargetInvocationException (from reflective
    Activator.CreateInstance) vs. bare parse exceptions (direct calls).
  • IsParseError — predicate used in the catch filter.
  • ParseError — maps a parse exception to the matching 400 body
    (instance_parse_error / reduction_input_parse_error /
    certificate_parse_error), reusing the existing body builders.
• reduce, gadgets, visualizeReduction, and visualize each gain a single
  catch (Exception ex) when (IsParseError(ex)) => ParseError(ex) arm. These
  previously let a ProblemParseException/ReductionInputException escape as an
  unhandled 500 (the reduce path was the endpoint in the reported Reduction/visualization endpoints return 500 (with stack trace) instead of 400 on unparsable instances #355 trace).
• mapSolution is refactored onto the same helper, collapsing its three inline
  catch blocks into one arm — all reduction/visualization endpoints now handle
  parse errors uniformly. verify/solve/problemInstance are left as-is.

Scope note

This closes the endpoint layer of #355: all five endpoints now translate a
typed parse exception into a 400. Inputs whose underlying problem/reduction
still throws a raw (non-typed) exception will continue to 500 through these
endpoints; converting those constructors to throw typed parse exceptions is a
per-problem effort tracked separately.

Verification

dotnet build Redux.slnx — 0 warnings, 0 errors.
dotnet test Redux.slnx — 687 passed, 0 failed, including new endpoint
tests asserting 400 + instance_parse_error for reduce, gadgets,
visualizeReduction, and visualize, plus the existing mapSolution
parse-error tests.

Live against a running backend (/ProblemProvider/mapSolution):

Input	Before	After
valid SAT3 solution → SipserReduceToCliqueStandard	200	200
clique-shaped cert → SipserReduceToCliqueStandard	500 IndexOutOfRange	400, 3SAT cert format, missing ':' separator
non-Sipser CLIQUE instance → SipserReduceToSAT3	500	400, CLIQUE instanceFormat + Sipser addendum
bad certificate → SipserReduceToSAT3	500	400, CLIQUE certificateFormat + Sipser addendum

No unhandled exceptions in the server log across all cases.

🤖 Generated with Claude Code