Emit the ILogger category as a queryable top-level field in JSON log format

[madmox]

Describe the feature

Follow-up to #2469 / #2474. The merged fix prepends the ILogger category to the rendered message as literal text ([MyApp.MyService] ...), which restores visibility but not queryability. This request is for the category to also surface as a dedicated field in the JSON log record, so it can be filtered and aggregated on.

In #2474 the author deliberately left this out as being a maintainer's call on the emitted JSON shape, and offered to do it as a follow-up PR; a maintainer agreed it could be one. This issue is that follow-up request.

Use Case

The category is the primary key for locating .NET logs ("which class emitted this?"). As a substring of message, the only option in CloudWatch Logs Insights is:

filter message like /MyApp.Filters.MyFilter/

A dedicated field enables the queries that text-format users lose when migrating to JSON:

filter Category = "MyApp.Filters.MyFilter"
stats count(*) by Category

Proposed Solution

Two possible levels:

1. Bridge-level (no runtime change): in LambdaILogger's JSON branch, emit the category as a named template parameter: prepend a "[{Category}] " placeholder and insert the category as the matching argument. The existing formatter turns named parameters into top-level JSON properties, so this yields a queryable Category field. Positional templates ({0}, {1}) cannot mix with a named placeholder, but they are detectable (all placeholder names numeric), so those can keep the current literal-text form as a fallback.

2. Envelope-level: a native category field written by JsonLogMessageFormatter next to timestamp/level/message. Cleaner (no message-text coupling, works for positional templates too), but requires plumbing the category through the parameterized logging API and a managed-runtime deployment, as with ConfigureStructuredLogging (Allow custom JsonSerializerOptions (and converters) in JsonLogMessageFormatter #2350).

Option 1 seems like the pragmatic first step; option 2 the better long-term shape.

Other Information

Emitting a new property changes the JSON shape and could collide with a user-supplied {Category} log parameter, so gating it behind an option (e.g. reusing IncludeCategory, or a dedicated EmitCategoryProperty) may be preferable to changing the default.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS .NET SDK and/or Package version used

Amazon.Lambda.Logging.AspNetCore 5.0.0 (+ the merged but not yet released #2474)
Amazon.Lambda.Core 3.3.0

Targeted .NET Platform

.NET 10 (managed dotnet10 runtime)

Operating System and version

Amazon Linux 2023 (Lambda managed runtime)

[madmox]

cc @TemRevil, who offered in #2474 to take this as a follow-up PR.