Add DealSignal object for buyer-initiated deal reactivation (RESUME_REQUEST)

[ChrisBasis]

Summary

Adds a lightweight, buyer-initiated way to request resumption of a paused or dormant deal. This fills a gap in the v1.1 lifecycle model: today only the seller can move a deal from PAUSED or LIVE_NOT_SPENDING back to LIVE, and a buyer with demand ready to spend has no in-band way to signal readiness, since buyerstatus is the buyer's own operational view and does not drive seller delivery.

What's added

• Object: DealSignal (deal1.1.md): a non-obligating push message carrying no term fields and no negotiationstatus. The first defined signaltype is 0 = RESUME_REQUEST.
• Buyer-Initiated Reactivation section (implementation-guidance.md): non-obligating behaviour, terminal-state handling (reuses the existing terminal-dominance rule, returning HTTP 409), terms-awareness via liverevisionid, and idempotency via signalid.
• The idempotency and conflict-resolution summary tables gain RESUME_REQUEST rows.

Design notes

• Reuses existing machinery: the seller resumes via the already-defined PAUSED to LIVE transition. No new status transition and no acknowledgement message are introduced.
• Distinguishes paused (resumable) from terminal (COMPLETED, EXPIRED, CANCELED, not resumable) using the existing enum and terminal-dominance rule.
• Available only under the bidirectional model; under seller-push-only the buyer cannot push.

Consistency edits

• Push endpoint message types updated from "two" to "three", and the payload-discrimination guidance now covers DealSignal.
• Table-of-contents entries added in both files.

Deliberately out of scope

A symmetric seller-to-buyer signal and a formal acknowledgement object, noted as possible future extensions.