[Generated Runtime] Use typed body-limit errors instead of matching error strings

[cssbruno]

Priority

Medium — generated handler correctness and Go-version resilience.

Context

Generated action/form parsing code detects oversized request bodies by checking whether err.Error() contains the text "request body too large" after ParseForm or ParseMultipartForm fails.

The request body is capped with http.MaxBytesReader, but the generated branch classifies the resulting error through string matching.

Problem

String-matching error messages is brittle.

Risks:

1. Go's wrapped error text can change across versions.
2. Localization or upstream wording changes can break classification.
3. A different parsing error could contain the same phrase and be misclassified.
4. Generated code should model request-limit failures as typed behavior, not textual heuristics.

The intended behavior is stable: body-limit failures should return 413 Request Entity Too Large; ordinary malformed form data should return 400 Bad Request.

Proposed direction

Use typed error detection in generated handlers.

For example, generated code can use errors.As(err, *http.MaxBytesError) or a small runtime helper:

if gowdkapp.IsRequestBodyTooLarge(err) {
    writeError(http.StatusRequestEntityTooLarge, "request body too large")
    return true
}

A runtime helper keeps generated source smaller and centralizes compatibility handling.

Acceptance criteria

• Generated action and contract form parsing no longer uses substring matching for body-limit errors.
• Body-limit detection uses errors.As or a runtime helper with typed checks.
• Oversized urlencoded and multipart form bodies return 413.
• Malformed non-oversized form bodies return 400.
• Tests cover wrapped http.MaxBytesError and unrelated errors containing similar text.
• Generated code remains gofmt-stable and deterministic.