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

### 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` (#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
- [x] 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)

Start by locating LambdaILogger's JSON branch and JsonLogMessageFormatter, then review the related changes in #2469 and #2474. Confirm with maintainers whether the bridge-level or envelope-level approach is wanted, including handling positional templates and collisions with user-supplied Category parameters. Done means the agreed JSON output exposes the ILogger category as a queryable field with appropriate coverage.

Written by the indexing model from the issue text.