ConfigLoader ignores requestBody on inline config-file endpoints

Description

docs/TESTING_GUIDELINES.md's "Grey-box via known request shapes" section documents that a config-file endpoint block can supply a real request body, and that injection test cases (ASTF-INJECTION-2023, ASTF-API10-2023) prefer that real sample body over a generic guessed field list.

ConfigLoader.java doesn't actually implement this. In the inline endpoints array parsing (ConfigLoader.java:276), every constructed EndpointInfo hardcodes the request body to null:

inlineEndpoints.add(new EndpointInfo(path, method, "application/json", null, requiresAuth));

No requestBody (or similarly named) field is ever read from the JSON/YAML node, even though EndpointInfo itself supports carrying one (used elsewhere via --endpoints-file + discovery-derived samples).

Impact

Any injection-focused test case that falls back to COMMON_BODY_FIELDS-style generic field names when no real body is known will silently miss fields with non-generic names (e.g. coupon_code, conversion_params) on any endpoint whose only body source is a config file — there's currently no way to hand the CLI a real sample body short of live discovery or an OpenAPI spec.

Found while live-verifying docs/TRACEABILITY.md row 13 (crAPI's apply_coupon endpoint) in #124 — needed to supply {"coupon_code": ..., "amount": ...} as a sample body via config file and discovered it's silently dropped.

Suggested fix

Read an optional requestBody (string or JSON object, serialized to a string) field from each inline endpoint node in ConfigLoader.java's endpoint-parsing block, and pass it through to EndpointInfo instead of the hardcoded null.

Start in ConfigLoader.java around line 276, then inspect EndpointInfo to confirm how request bodies are carried. Compare the inline endpoint parsing with the documented request shape in docs/TESTING_GUIDELINES.md. Done means an optional requestBody string or JSON object from an inline endpoint reaches EndpointInfo and is available to the injection test cases.