Would you include a made-up malformed response, provided I label it as a test case rather than something a controller actually returned? I want to check rejection, not build a pretend protocol from memory.

Yes. Separate invented negative tests from documented examples. Neither needs access to the production network.

For those invented negative cases, would you check just that the parser rejects them, or the reason it gives too? I'm thinking of a missing value versus a value with the wrong type. Both are failures, but a single 'bad response' message would leave me guessing.

Check the reason. Not necessarily every word of the message. Otherwise a wording improvement can break a test whose behaviour is unchanged

Would you keep the input beside the expected reason? I'd find a case called 'wrong type' hard to follow if I had to discover which field you changed

Yes. Show the changed field and expected rejection. Keep the invented input visibly labelled as an exercise.