Consolidate API/client DTO types to single source (OpenAPI or shared package)

[lsmonki]

Context

Specs client:dto-* require DTO types to be imported from a shared package or generated from the same schema source as @specd/api / OpenAPI. Today @specd/api and @specd/client maintain hand-written parallel interfaces (e.g. GraphStatusDto, ProjectGraphSummaryDto, GraphHealthWarningDto).

Parity is enforced today by TypeScript compile + presenter/integration tests, but manual duplication risks silent drift when one side changes without the other.

Problem

• Two sources of truth for wire shapes (packages/api/src/delivery/http/dto/* vs packages/client/src/dto/*)
• New fields (like warnings[], fingerprintMismatch) must be updated in both places
• Spec wording expects single-source or codegen, not mirror-by-convention

Proposed directions (pick one in design)

1. OpenAPI → client codegen — generate or re-export client types from the same OpenAPI/Zod schemas that feed API presenters
2. Shared @specd/dto (or similar) — move wire DTOs to a small package consumed by both api and client
3. Client re-exports API types — if dependency direction allows (may conflict with current layering)

Acceptance criteria

• One canonical definition per wire DTO used by Studio remote + embedded paths
• Adding a required API field fails build without updating the single source
• client:dto-* spec scenarios for "types are shared or generated" satisfied without advisory caveat
• Document migration approach for existing mirrored interfaces

References

• Change: studio-graph-health-warnings
• Compliance report: specd-sdd/changes/20260701-090344-studio-graph-health-warnings/reports/20260701-163015/specs-compliance-change-studio-graph-health-warnings-20260701-163015.md
• Related specs: api:dto-graph-status, api:dto-project-status, client:dto-graph-status, client:dto-project-status

Priority

Low / tech debt — no production defect identified; follow-up after graph health warnings ships.