FwLiteWeb mini-lcm routes return 500 instead of 404/400 for not-found and bad-request cases

[imnasnainaec]

Problem

The endpoint filter in MapMiniLcmRoutes (backend/FwLite/FwLiteWeb/Routes/MiniLcmRoutes.cs:60-96) reports all of its own failure cases via Results.Problem(...) with no statusCode argument:

• MiniLcmRoutes.cs:68 — invalid projectType route value
• MiniLcmRoutes.cs:74 — missing/blank projectCode
• MiniLcmRoutes.cs:87 — projectCode doesn't resolve to a known project (projectProvider.GetProject(projectCode) returned null)

Results.Problem defaults statusCode to 500 (Internal Server Error) when omitted, and FwLiteWeb has no exception-handling middleware (FwLiteWebServer.cs) that remaps it. So every mini-lcm/{type}/{code}/... route (writingSystems, entries, entry/{id}, etc.) returns an identical 500 whether:

• the project code was mistyped or never existed,
• the project existed but was deleted, or
• something is actually broken server-side.

A caller has no way to distinguish "this project doesn't exist" from "the server has a real problem" from the status code alone.

Impact

Found while reviewing #2394's lexicon self-healing logic: the extension re-checks a project's stored lexicon code before using it, and wants to clear that setting only when the backend confirms the lexicon is gone (e.g. deleted in FW Lite) — not when a request fails for some unrelated reason (backend still starting up, transient network blip, genuine server error). Because every failure mode currently surfaces as the same 500, the client can't make that distinction without brittle string-matching on the ProblemDetails.detail message. Any other FW Lite client hits the same ambiguity.

Suggested fix

Give each Results.Problem(...) call in the filter an explicit, correct status:

• MiniLcmRoutes.cs:87 (project not found) → statusCode: StatusCodes.Status404NotFound
• MiniLcmRoutes.cs:68 (invalid projectType) → statusCode: StatusCodes.Status400BadRequest
• MiniLcmRoutes.cs:74 (missing projectCode) → statusCode: StatusCodes.Status400BadRequest

Project resolution itself is fine — CrdtProjectsService.GetProject and FieldWorksProjectList.GetProject both return null cleanly for unknown codes rather than throwing. The bug is purely in how the filter maps that null (and the other two failure cases) to an HTTP status.

---

Drafted by Claude Sonnet 5 (claude-sonnet-5).