## Why

The existing architecture delivery stream is stale: it still points at `implement-server-management-workflows` as active even though the repository now contains many completed changes, while `fix-env-profile-settings` remains open only because browser walkthrough evidence is missing. The project also needs a repeatable "one OpenSpec per fresh chat" queue so future work stops feeling like a demo and advances through verifiable platform capabilities instead of broad, mixed-scope conversations.

## What Changes

- Refresh the architecture delivery stream so it reflects the current OpenSpec state and no longer names completed work as active.
- Add a serial OpenSpec delivery queue that records the next concrete change to create, the prompt to use in a fresh chat, and the stopping rule for that chat.
- Add a next-change pointer so a new chat can continue from the queue without rediscovering the whole plan.
- Define a generator protocol: finish or unblock the current active change, create exactly one next OpenSpec, validate it, update the pointer, then stop.
- Seed the queue with product-readiness OpenSpecs focused on proving and completing real platform behavior: server creation, run-mediated operations, durable logs, artifact transfer, plugin marketplace, user management, AI provider settings, local debugging, and browser acceptance.
- Preserve the platform scope: no billing, cloud host sales, unrelated SaaS marketplace features, raw AI key exposure, or direct plugin/browser access to run.

## Capabilities

### New Capabilities

- `serial-openspec-delivery-queue`: Defines the queue, next-change pointer, generator rules, handoff prompts, and verification gates for creating one future OpenSpec at a time.

### Modified Capabilities

- None.

## Impact

- Affects OpenSpec planning files under `openspec/changes/architecture-delivery-stream/`.
- Creates planning artifacts only; this change does not implement platform, run, frontend, or plugin product code.
- Future generated changes will touch `platform/`, `run/`, `platform_web/`, and `plugins/` according to their own OpenSpec scopes and verification gates.