[Bug] Code generation produces invalid C# string literal for Scrutor-decorated keyed services in 6.0.1

[elitonperoni]

When using Scrutor's .Decorate<>() to decorate a service registered as ICommandHandler<TCommand, TResponse>, Wolverine 6.0.1 generates invalid C# code during runtime compilation. The generated service key contains an unescaped double-quote character, causing a compilation error at startup.
This worked correctly in 6.0.0.

Steps to Reproduce

1 Register a command handler with Scrutor decoration:

services.AddScoped<ICommandHandler<SendBidCommand, SendBidDtoResponse>, SendBidCommandHandler>();
services.Decorate<ICommandHandler<SendBidCommand, SendBidDtoResponse>, SendBidCommandHandlerDecorator>();

2 - Configure Wolverine with TypeLoadMode.Auto:

builder.UseWolverine(opts =>
{
opts.CodeGeneration.TypeLoadMode = TypeLoadMode.Auto;
// ...
});

3- Run the application and consume a message handled by the decorated handler.

Generated Invalid Code
Wolverine generates the following code, which does not compile:

// INVALID - unescaped double-quote inside string literal
var commandHandler = ServiceProviderKeyedServiceExtensions
.GetRequiredKeyedService<ICommandHandler<SendBidCommand, SendBidDtoResponse>>(
serviceScope.ServiceProvider,
"ICommandHandler"2+086d3e55674e4266aa5a200422decbfe+Decorated" // ← syntax error
);

The key "ICommandHandler"2+086d3e55674e4266aa5a200422decbfe+Decorated" is the raw internal key Scrutor generates for the decorated registration. The " inside the string is not escaped to ", breaking the generated C# source.

Expected Behavior: The generated key should be properly escaped:
"ICommandHandler"2+086d3e55674e4266aa5a200422decbfe+Decorated"

Environment:
Wolverine: 6.0.1 (works on 6.0.0)
Scrutor: (decoration via .Decorate<>())
.NET 9
Transport : RabbitMQ (WolverineFx.RabbitMQ)

Workaround
Pinning to 6.0.0 restores the previous behavior. Replacing Scrutor with a manual lambda factory registration also avoids the issue.

[jeremydmiller]

@elitonperoni We're not going to be able to support this most likely and you'll need to switch to pure service location. Happy to take pull requests, but I don't see this being something we can just flip a switch on.

FWIW, we could make this work w/ the old Lamar support for Decorators where Lamar inlined the decorator construction. Scrutor does it a hokey way.

And why in the world would you be using something like ICommandHandler<SendBidCommand, SendBidDtoResponse>, SendBidCommandHandler>() within Wolverine? That smells like a homegrown MediatR tool.

[jeremydmiller]

Moving this to a discussion because I don't think this is actionable