feat(ai): gracefully handle ui message validation in output-error scenarios

[mwln]

Background

The validateUIMessages utility function does not cover the potential input
and rawInput states for output-error scenarios properly. In the case that a
tool fails due to a schematic error in input, the validation of that
ToolUIPart of { state: "output-error" } fails its schematic check against
the tool's inputSchema, creating an invalid messages array despite the array
being technically valid based on it's type. see ToolUIPart

The main reason this happens is due to:

1. the schemas defined in the validation aren't directly covering all possible scenarios
   that the type defines
2. the output-error scenario still forces a schematic check on the input, even if the
   input does not exist. In these scenarios, the part returned actually uses the rawInput
   property to portray that failed input.

The tests for this function do not cover this particular state, which allows the
test-suite to pass gracefully despite this potential state occurring in real-world
scenarios.

Manual Verification

• test the scenario where unhandled, yet valid, input scenarios fail the test suite
• ensure the schema is only checked when it makes sense for output-error's.

Tasks

• add additional test case for scenario
• A patch changeset for relevant packages has been added
• Formatting issues have been fixed (run pnpm prettier-fix in the project root)
• I have reviewed this pull request (self-review)

[lgrammel]

revert all the nullish changes and the docs changes

[mwln]

revert all the nullish changes and the docs changes

@lgrammel fair enough.

Just a note though - since these schema's are only used in this function, and the validation function is only exported as a nice-to-have, there's not much reason to block the support of a wider range of falsy/nullish scenarios on set properties.

I'd argue the utility of the function is just to validate the bare minimum requirements for a UIMessage to display it's necessary information, which is in most cases just the type and then the messages core information given its state.

The omitted/undefined/nullish/falsy scenarios for properties kind of becomes unimportant at that point, which then questions the utility of this function if its going to throw errors unless all the aforementioned property scenarios are coerced to undefined.