UMCPHandler_SetClassDefaultValue - Refactoring Notes

What was done

Converted to plain-text output. Switched from Handle(Json, FJsonObject*) to Handle(Json, FStringBuilderBase&). All error messages and results go through the string builder.
Removed UE_LOG call. The log line at the end has been removed; the result is reported via the response instead.
Trimmed includes. The original had ~40 includes, most of which were unnecessary for this handler. Reduced to just the ones actually used.
Concise output. Instead of echoing back separate fields (oldValue, newValue, propertyType, saved), the success output is a single line like TSubclassOf<AActor> MyProp: OldClass -> NewClass. Save failure is reported as a warning only when it actually fails.
Used MCPUtils::FormatName() consistently. All object names in output (blueprint, class, meta-class) use FormatName. The old code used *Blueprint (the raw input string) in some error messages instead.
Extracted ResolveClass helper. The class-resolution logic (C++ class iteration + blueprint asset fallback) was pulled into a private method to reduce nesting in the main Handle method.
MCPAssetFinder error reporting. All MCPAssets calls pass Errors(Result) so errors go directly to the caller.

The handler covers three distinct property type families (class refs, object refs, simple types) which is genuinely useful breadth.
The MCPAssetFinder usage was already mostly in good shape; just needed error callback modernization.

Object property branch: The original code assumed the Value is always a Blueprint name and resolved it to the CDO. This is a narrow interpretation of "object property" - it won't work for setting an object property to a StaticMesh, Texture, or other non-Blueprint asset. I preserved this behavior rather than expanding it, since I'm not sure what use cases are intended. This branch could benefit from a more general asset resolution approach.
ResolveClass C++ iteration: The TObjectIterator<UClass> loop to find C++ classes is O(n) over all loaded classes. I preserved it as-is since there isn't a clear better alternative in the existing utilities (MCPUtils::FindClassByName exists but I wasn't sure if its behavior matches exactly). Worth investigating whether MCPUtils::FindClassByName could replace the manual iteration.
No batching. This handler operates on a single property at a time. It could potentially be extended to accept an array of property/value pairs, which would be useful when configuring multiple defaults on one blueprint. I did not add this since the coding standards say to batch "where it makes sense" and this felt like a judgment call for the architect.
SoftClassProperty path: The FSoftObjectPtr construction for soft class properties was preserved as-is. I'm not 100% certain this is the correct way to set a TSoftClassPtr value, but it matches the original code.