Survey response-side read-models (parse vs TypedDict)

[mocha06]

Part of the "Typed payloads: parse, don't validate" milestone.

Goal — survey, not a blanket migration

The response-side *GraphPayload / TypedDict payloads (services/types.py, services/automation_graphql_types.py, and the many *_tool_helpers.py TypedDicts) describe shapes but validate nothing — consumers still .get() into them and re-derive types.

This is a bounded survey, not a migration: decide, per boundary, where parsing into a validating model actually pays off (invariants that consumers currently re-check, dual-reads that mask query drift) versus where a TypedDict is fine (pure pass-through to a serializer).

Deliverable

• A short findings doc: for each response boundary, "parse / leave as TypedDict / align query" with a one-line rationale.
• Spin off follow-up issues only where parsing removes real downstream re-checking. Do not convert TypedDicts wholesale — response models that guard nothing are the over-engineering this milestone is meant to avoid.

Note

Input-side typing (issues in this milestone) is the higher-value work — the API enforces input shapes, so a wrong wire name is a hard failure. Response typing only pays when our code re-derives invariants the payload already guarantees.