Expose the complete Sidekick.Todo editing contract before repeated validation failures #1210

Story

As Sidekick editing the shared checklist, I want one discoverable working invocation and a complete first-error explanation, so I do not have to probe Markdown body, JSON body, missing as, and diff fencing in separate turns.

Existing contract

The shipped todo-components.md example uses Sidekick.Todo as="items" for reads and a paired form containing exactly one fenced unified diff for writes. Guide.Environment points to this contract. Preserve stale-patch refusal and the session-owned checklist; do not replace it with arbitrary file writes.

Required outcome

• Make the exact read/write example and required properties available from the response capability help at the point of use.
• The first malformed write should explain the accepted shape together, including binding/capture requirements, one fenced diff, and read-before-patch guidance, while identifying the actual error.
• Evaluate whether the current common interaction is needlessly complex before freezing implementation; a simpler operation would require an explicit contract decision, not an undocumented alternative parser.
• Clarify response-control versus ordinary-entry placement. In the cleanup, entry95 actually contained Sidekick.Todo after successful shell effects and then failed; placement errors should be explained without claiming those earlier effects were rolled back.
• No extra schema-discovery model calls or mandated large guide injection.

Acceptance

A reader can form a valid read and edit using the advertised example. Controlled malformed body, missing property, wrong fence, stale source and misplaced invocation yield complete actionable diagnostics without mutating the checklist. Successful use retains the same history, permissions and feedback ownership.

Context and delivery boundary

Requested from the architecture-cleanup Fable retrospective and subsequent maintainer review. Retrospective claims are not automatically established defects; use the cited concrete witnesses and controlled examples. This ticket records backlog work, not a new active lane, automatic recovery policy or authorization to change unrelated work. Keep the change bounded and update the relevant shipped guidance and owning specification together.

Pilot scheduling update

The maintainer selected higher-value work for the second pilot pair instead (#1178 and #1183). This issue is returned to the backlog; no pilot implementation was dispatched and no completed work was replayed.