fix(daemon): show DSH usage attribution in execution diagnostics

[lefarcen]

Why

A QA incident report showed that DeepSeek Harness usage frames already carried provider and model metadata, but the daemon execution diagnostics still reported both fields as not collected. The diagnostics summarizer only consulted assistant-message lifecycle diagnostics, which this runtime does not emit.

This focused fix preserves the runtime attribution already available on successful DSH runs without changing the DSH protocol, analytics pipeline, model selection, or message lifecycle accounting.

What users will see

Execution diagnostics for DeepSeek Harness runs now show the runtime-reported provider and resolved model instead of not collected. Assistant-message counts and durations remain explicitly unavailable when the runtime does not expose lifecycle events.

Surface area

• UI — new page / dialog / panel / menu item / setting / empty state in apps/web or apps/desktop (including Electron menu bar)
• Keyboard shortcut — new or changed
• CLI / env var — new od subcommand or flag, new tools-dev / tools-pack flag, or new OD_* env var
• API / contract — new /api/* endpoint, new SSE event, or changed shape in packages/contracts
• Extension point — new entry under skills/, design-systems/, design-templates/, or craft/, or change to the skills protocol
• i18n keys — added new translation keys
• New top-level dependency — adding any new entry to the root package.json
• Default behavior change — execution diagnostics now use runtime usage attribution as a fallback
• None — internal refactor, docs, tests, or translation update only

Screenshots

Not applicable: this changes daemon-owned diagnostic values and introduces no UI surface.

Bug fix verification

• Test path that reproduces the bug: apps/daemon/tests/runtimes/runs.test.ts
• Did the test go red on main and green on this branch? Yes. The red spec reproduced provider and resolvedModel as not_collected before the source change, then passed after the fallback was added.
• The companion precedence test confirms existing lifecycle attribution still wins over usage metadata.

Validation

• pnpm --filter @open-design/daemon exec vitest run tests/runtimes/runs.test.ts — 47 passed
• pnpm --filter @open-design/daemon exec vitest run tests/agent-protocol/dsh-profile.test.ts tests/run-analytics-observability.test.ts tests/runtimes/runs.test.ts — 117 passed
• pnpm --filter @open-design/daemon typecheck
• pnpm guard
• pnpm typecheck
• git diff --check
• Real local E2E: isolated daemon data root → official dsh 0.1.0-rc.6 open-design profile → deepseek-official/deepseek-v4-flash → successful response → GET /api/runs/:id reported provider=deepseek-official and resolvedModel=deepseek-v4-flash while assistant-message lifecycle metrics remained not_collected. The isolated daemon was stopped after verification.

[lefarcen]

🧪 Queued for QA validation — this PR changes runtime diagnostics that can affect what users see when they inspect execution diagnostics, so it will go through a manual QA pass before merge. Nothing needed from the author right now; we will update here once it is validated.

[nettee]

@lefarcen

I reviewed the DSH runtime diagnostics fallback in apps/daemon/src/runtimes/runs.ts and its focused regression coverage. Lifecycle provider/model attribution still takes precedence, while the validated DSH usage metadata fills those fields when lifecycle events are unavailable. The live diff stays scoped to the intended daemon and test ranges.

Verification: 117 focused daemon tests, daemon typecheck, repository guard, and workspace typecheck all pass. Nice focused fix—thank you for pairing the runtime contract with a precedence regression test!

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[open-design-release-bot]

Successfully created backport PR for release/v0.20.0:

• [backport release/v0.20.0] fix(daemon): show DSH usage attribution in execution diagnostics #7078