[GENERAL ISSUE] - cfn-guard-lambda response parsing seems like a bit much

**Describe the issue**
The cfn-guard-lambda response is very verbose and seems to require a good chunk of knowledge about the inner workings of the tool to parse and that feels cumbersome enough that I am hoping to double check that I am using the available tools appropriately.

To avoid the xy problem i'll describe the general problem I'm trying to solve:
* we have a lot of small repos that each have their own cfn templates and I was hoping to use cfn-guard to enforce some org wide rules against some resources that may be in the templates.
* to run cfn-guard against the myriad of repos i was planning to create a github org wide webhook on PR events that would hit a lambda that would be deployed with the org ruleset and run it against a template (if in the PR diff) via a separate cfn-guard-lambda
* the webhook lambda would parse the results and relay them as a github check to the PR

As I'm digging into parsing the nested response of the lambda it feels like i'm going to be recreating a component of what `cfn-guard` natively already does in order to capture what rules actually failed, with their messages, and where they failed in the template.

**Any examples**
Output from `cfn-guard` cli:
[cfn-guard-cli.txt](https://github.com/user-attachments/files/17282772/cfn-guard-cli.txt)

Output from `cfn-guard` lambda (same ruleset/template):
[cfn-guard-lambda.json](https://github.com/user-attachments/files/17282776/cfn-guard-lambda.json)

The information is all there in the lambda output so I don't think this is a bug or anything. I'm half asking for a sanity check that there isn't a way to use the cfn-guard lambda that bubbles up the summary like the cli does and ultimately probably going to ask for a feature request to create that or at least some example code in the docs as a reference point

Start by comparing the attached cfn-guard-cli.txt and cfn-guard-lambda.json outputs for the same ruleset and template. Read the cfn-guard Lambda response entry point and determine whether the CLI-style failure summary is an existing capability or a new API requirement. Done should be a decided, documented approach or a clearly scoped feature request with expected response output.

Written by the indexing model from the issue text.