afterCommand hook context lacks before/after item state (e.g. previousStatus) — blocks transition-aware extensions #107

Summary

AfterCommandHookContext gives a command-level view but no item-level before/after state, so extensions cannot reliably detect status transitions (e.g. draft → open, open → canceled).

Current shape (SDK 2026.5.31, core/extensions/extension-types.d.ts)

interface BeforeCommandHookContext { command: string; args: string[]; options?: Record<string, unknown>; global?: GlobalOptions; pm_root: string; }
interface AfterCommandHookContext extends BeforeCommandHookContext { ok: boolean; error?: string; result?: unknown; }

result is unknown and there is no previousStatus / prior front-matter snapshot.

Why it matters

Lifecycle/notification extensions (e.g. pm-slack) want to fire on the transition, not just the terminal state. Today, on pm update --status open, an afterCommand hook can read the new status from options/result but cannot know the item was previously draft, so it can't distinguish reopen vs open vs unblock. The detection logic ends up forward-compatible-but-inert.

Proposed

Add to AfterCommandHookContext (or a typed result) the affected item id(s) plus a previousStatus/previous front-matter snapshot and the resulting status — e.g.:

interface AfterCommandHookContext extends BeforeCommandHookContext {
  ok: boolean; error?: string; result?: unknown;
  affected?: Array<{ id: string; previousStatus?: ItemStatus; status?: ItemStatus; previous?: Partial<ItemFrontMatter>; }>;
}

This is additive (optional field) and unlocks transition-aware notifications/automation. Distinct from #104 (onWrite ctx identity) — this is the command hook surface.