[BUG] Desktop app ignores OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES from project .claude/settings.json

## What's Wrong?

The desktop app's built-in agent does not apply `OTEL_SERVICE_NAME` or `OTEL_RESOURCE_ATTRIBUTES` from the project's `.claude/settings.json`, even though it *does* apply `CLAUDE_CODE_ENABLE_TELEMETRY` and `OTEL_EXPORTER_OTLP_ENDPOINT` from the very same `env` block (telemetry is exported normally to the configured collector, so the file is clearly being read).

The CLI, run in the same directory with the same settings file, applies all of them correctly.

We set `OTEL_RESOURCE_ATTRIBUTES=project=` per repository so Claude Code token/cost telemetry can be attributed to the right internal initiative (governance / chargeback). Metrics from desktop-app sessions arrive with no `project` attribute at all, so that spend cannot be attributed to any project.

Measured on our collector over 7 days: 27 desktop sessions / 411 datapoints, none carrying `project`; 90 VS Code sessions / 54,383 datapoints carrying `project` as expected.

## What Should Happen?

Both clients export the resource attributes configured in the project's `.claude/settings.json`:

- `service.name` = the value of `OTEL_SERVICE_NAME`
- a `project` resource attribute from `OTEL_RESOURCE_ATTRIBUTES`

i.e. the desktop app should honor the same `env` block the CLI honors.

## Error Messages/Logs

```shell
# Metric dimensions from a DESKTOP session (project attributes missing):
service.name = claude-code-desktop <-- expected: value of OTEL_SERVICE_NAME
terminal.type = non-interactive
project = <-- expected: MY-PROJECT
instrumentationlibrary.name/version = com.anthropic.claude_code / 2.1.271

# Metric dimensions from a CLI session, same folder, same settings file:
service.name = my-service <-- correct
terminal.type = mingw64
project = MY-PROJECT <-- correct
```

## Steps to Reproduce

1. In a project folder, create `.claude/settings.json`:

```json
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
"OTEL_EXPORTER_OTLP_ENDPOINT": "https://your-otel-collector.example.com",
"OTEL_SERVICE_NAME": "my-service",
"OTEL_RESOURCE_ATTRIBUTES": "org.name=acme,deployment.environment=dev,project=MY-PROJECT"
}
}
```

2. Open that folder in the Claude desktop app (Code tab) and send any prompt.
3. Inspect the metrics received by the collector: they arrive (endpoint honored), but with
`service.name=claude-code-desktop` and no `project` attribute.
4. In the same folder, from a terminal, run `claude -p "ok"`.
5. Inspect the metrics again: `service.name=my-service` and `project=MY-PROJECT` are present.

Note: no environment variables are set at the OS level in either case; the only source of
configuration is the project's `.claude/settings.json`.

## Claude Code Version

2.1.275 (Claude Code CLI); desktop app 2.110.1 (instrumentation 2.1.271)

## Platform / OS / Terminal

Anthropic API / Windows / Claude desktop app

## Additional Information

**Workaround attempted and rejected**

Setting `OTEL_RESOURCE_ATTRIBUTES` as an OS-level (user scope) environment variable is not a viable
workaround: we verified that an inherited environment variable **overrides** the per-project
`.claude/settings.json`. A global value would label every repository with the same `project`, which
defeats the purpose. (Secondary question: is that precedence intended? We would expect project
settings to take precedence over an inherited environment variable.)

**Questions**

1. Is the desktop app expected to ignore `OTEL_SERVICE_NAME` / `OTEL_RESOURCE_ATTRIBUTES` from project settings? If so, is that documented?
2. Is there a supported way to set OTel resource attributes per project for desktop-app sessions?
3. If this is a bug, is there a workaround we can adopt in the meantime?

Happy to provide more collector-side details if useful.

Start by comparing how the desktop app's Code tab and the CLI entry point invoked by `claude -p` load the project's `.claude/settings.json` environment block. Reproduce with the provided OTel settings and inspect collector output for `service.name` and `project`; done means desktop sessions honor both resource settings like CLI sessions.

Written by the indexing model from the issue text.