#11530: diagnostics-otel: fix OpenTelemetry v2 resource/logs API compatibility

## Summary Fixes `diagnostics-otel` startup failures after upgrading OpenTelemetry dependencies. Root cause was API drift in OTel v2: - `@opentelemetry/resources`: `new Resource(...)` is no longer the supported constructor path. - `@opentelemetry/sdk-logs`: `LoggerProvider#addLogRecordProcessor` is no longer available. ## Changes - Switch resource creation to `resourceFromAttributes(...)`. - Initialize `LoggerProvider` with `processors: [...]` instead of calling `addLogRecordProcessor(...)`. - Update the extension unit test mock from `Resource` to `resourceFromAttributes`. ## Why this matters Without this patch, `diagnostics-otel` fails during plugin startup and telemetry export is disabled at runtime. ## Validation - `pnpm vitest run extensions/diagnostics-otel/src/service.test.ts` - Manual runtime verification on a live gateway: - plugin starts successfully - `diagnostics-otel: logs exporter enabled (OTLP/HTTP)` appears in logs - no further plugin startup TypeErrors for diagnostics-otel <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates the `diagnostics-otel` plugin to match OpenTelemetry v2 API changes by switching resource creation to `resourceFromAttributes(...)` and constructing `LoggerProvider` with `processors: [...]` instead of calling `addLogRecordProcessor`. The runtime changes in `extensions/diagnostics-otel/src/service.ts` align with the described OTel API drift, and the unit test updates the resources mock accordingly. One issue remains in the test harness: the `@opentelemetry/sdk-logs` mock `LoggerProvider` still models the removed `addLogRecordProcessor` API and does not capture/validate the new `processors` constructor option, so the test can pass without actually asserting that processors are wired. <h3>Confidence Score: 4/5</h3> - Mostly safe to merge, but fix the unit test mock to reflect the new LoggerProvider initialization semantics. - The production change is small and directly addresses known OTel v2 API incompatibilities. The main risk is around test coverage correctness: the current sdk-logs mock can mask regressions because it doesn’t model the new `processors` option and retains an unused API. - extensions/diagnostics-otel/src/service.test.ts <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->