feat: RunPane workflow milestones, warning severity, and incremental output (epic #356 phase 5)

[parsakhaz]

Follow-up to epic #356, which shipped in #363. The epic's five phases were compressed to three at the owner's request and the budget ran out at the last item, so original phase 5 is entirely outstanding. Everything below is deferred work with its rationale already established — this issue exists so it is tracked rather than lost when #356 closes.

Outstanding acceptance criteria (from #356 phase 5)

• AC1 — WHEN an agent emits a milestone via panels events emit --type <ns>.<name> --data-file, subscribers shall receive an event carrying its namespace, schema version, producer, and an explicit agent-emitted (unverified) trust marker.
• AC2 — WHILE terminal text contains an authentication warning and the agent continues producing output, the state shall report the warning as blocking: false and shall not emit a blocked event.
• AC3 — WHEN the same warning persists unchanged, no additional warning event shall be emitted.
• AC4 — WHEN panels output --panel <id> --since <output-cursor> is issued, the response shall contain only output recorded after that cursor.

Verification: automated main-process integration tests plus the npm/Python parity run (scripts/test-runpane-contract.js), matching how #363 proved the rest of the epic.

Locked directions that still apply

• D5 — milestone events are namespaced, schema-versioned and trust-labeled claims. Daemon-derived and agent-emitted events stay distinguishable, and a milestone never grants authority for merge, deploy, release or publish.
• D3 — lifecycle and output cursors are separate namespaces. The durable SQLite table deliberately arrives here, with milestones, rather than in the event ring: milestones are the one genuinely replay-shaped payload that justifies a migration.
• D7 — additive only; npm CLI, daemon schema, generated contracts and the Python wrapper stay in parity.

Decisions already resolved (do not re-litigate)

• panels output --since reads persisted session_outputs rows, not serialized scrollback — the two are not 1:1. This closes the open question carried in feat: Event-driven RunPane orchestration #356.
• A two-namespace cursor design for milestones exists in tmp/356/plan-3.md (Group C) in the epic's worktree.

Also deferred, deliberately

Idempotent panes create retry via a caller-supplied request key. The obvious implementation does not work: creation is enqueued before a session exists, the queue unconditionally adds a job, the session UUID is generated inside creation, and sessions has no request-key column or uniqueness constraint — so two concurrent retries would both enqueue. A correct version needs an atomic durable reservation with its own migration. Not attempted rather than half-built.

Migrate renderer notifications onto the canonical attention layer. Per D4 in #356, two attention truths currently coexist: the renderer's activityStatus on its untouched 30s timer, and the orchestrator-facing agentActivity on the configurable debounce. Accepted for the epic, still owed.

Wire pnpm --filter runpane test into .github/workflows/quality.yml. The wrapper suite added in #363 does not run in CI. One line, kept out of that PR to avoid mixing a CI change into an already-large diff.

Suggested shape

Phase-5 ACs plus the CI one-liner are a single ticket. The idempotent-create work and the renderer migration each deserve their own, since both carry a migration or cross-process change.