[Feature Request] Draft changes as the capture point for off-scope findings during development

[Arteiimis]

The workflow gap

While implementing change A, I find a bug B that is unrelated to A. I don't want to fix B now — it would break the current change's atomicity and review story — but I need a cheap, lossless way to record it and come back after A ships. Today there is no such path in OpenSpec:

• A full change is too heavy: naming, proposal, later archive, and it pollutes the active-changes list and task-progress totals.
• Unstructured notes (chat history, scratch files) get lost.
• A proposal-only change (no checkbox tasks.md) already renders as a "Draft" in openspec view — exactly the right shape — but Draft is a derived UI group, not a concept of the system: it exists in neither the spec-driven schema, the artifact templates, the generated skills/instructions, nor the list/status data model. An agent (which does the recording mid-development) cannot be told to use a workflow that no delivered instruction describes, and nothing programmatic can enumerate the backlog.

Requested shape (small, presentation-only — no new commands, no lifecycle machinery)

1. Document Draft as a state: a change with zero checkbox tasks is a draft — a parking spot for ideas and off-scope findings. Add it to the delivered instructions (new-change workflow / templates) so agents know recording one is openspec new change <name> + a short proposal.md, nothing more.
2. Surface it consistently: list/status/list --json report drafts alongside what view already shows (out of active counts, out of progress totals). If the optional inert status field direction from Proposal: lifecycle: status — record change state as data, not directory position (experimental) #1683 is adopted, draft would be a natural third enum value (proposed/shipped both imply a claim on requirements; a draft claims nothing).
3. Promotion is already free: adding tasks.md moves the change into the active flow — no new transition command needed.

Out of scope: new file formats (the .napkin.md mechanism from #538 was declined), new commands, lifecycle modes, gates, or any change to archive semantics.

Context: #429 raised the same use case and was closed as covered by the Draft view group; this asks for the part that close explicitly left open — Draft as a first-class, documented, enumerable concept. #1684's maintainer review suggested scoping to an optional inert status field with list --status; this request fits inside that scope.