[csharp][generichost] Change logging category and add EventId

[devhl-labs]

Please merge this first: #24273

Problem

Generated C# generichost clients had two observability issues:

• logging in response paths could use the wrong logger category instead of the owning API category
• event IDs were missing, making log streams harder to analyze reliably

In generated ApiResponse classes, ILogger<T> should always point to the owning API type. If the category drifts, filtering and correlation drift with it.

The logger category matters because logging providers route and filter by category. If the wrong type ends up in ILogger<T>, logs from the response path appear under a different category than the rest of the API, breaking dashboard grouping, sink routing, and structured queries.

The category should be the API class, not the response class. Users think in terms of API operations, not response wrapper types. Setting "PetApi": "Debug" in appsettings.json to capture all traffic from that surface is intuitive. Hunting for generated response type names is not. The log events — request completed, failed, deserialization error — are semantically owned by the API call, not the response object that carries the result.

Event IDs give each log path a stable machine-readable identity, so alerts and queries remain reliable even when message text changes.

Solution

The template now stabilizes classname reuse in the duplicated-operation block before logger declarations are emitted.

The bin/configs/csharp-generichost-latest-tags.yaml sample exposed an edge case: when an operation is duplicated across multiple API classes, Mustache context at the point of logger declaration resolves to the wrong classname. Three small keyed text cache/recall lambdas (lambda.cache, lambda.recall, lambda.recallOnce) were added purely to work around this, keeping classname resolution deterministic in that case.

Result

Generated generichost response classes now consistently use the intended API logger category. Log events carry stable event IDs, making them reliable targets for alerts, queries, and dashboards regardless of future message text changes.

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.