Spec questions from messagebus model coverage (PIPELINE-1 / STOP-1)

Raised while adding validated pydantic models for the spec-defined messages (ovos-pydantic-models#6):

1. PIPELINE-1 §8 — the handler-lifecycle messages (ovos.intent.handler.start/complete/error) lack a canonical payload schema (unlike §9.1/§9.2/§9.6). Models currently infer skill_id + intent_name (+ optional pipeline_id) from the §7.1 dispatch shape. Should §8 define the payload normatively?
2. STOP-1 §4.2 — ovos.stop.pong payload: is a skill_id field expected for disambiguation on the shared reply topic, or is session propagation via reply() considered sufficient? (Modeled as Optional pending verification against ovos-stop-pipeline-plugin.)
3. PIPELINE-1 §9.6 — ovos.utterance.speak vs the legacy speak TTS dispatch are distinct layers; consider a spec note clarifying the relationship for consumers.

Review the referenced ovos-pydantic-models#6 coverage alongside PIPELINE-1 §§7.1, 8, and 9.6 and STOP-1 §4.2, then verify the ovos-stop-pipeline-plugin behavior. Done means the payload expectations are resolved and the relevant specifications clearly document the canonical schemas and relationship between the message layers.