docs: a hosted demo or playground

Evaluating FlexiQ requires installing it. That is a low bar for the Python SDK — pip install
and a SQLite file — and a much higher one for the thing worth showing: a server, a dashboard, a
worker, and jobs moving between them.

A hosted demo removes that step:

• a running flexiq-server with the dashboard, seeded with jobs in every state — succeeded,
  retrying, dead-lettered, a running workflow, a job parked in step.sleep
• read-only, or reset on a timer, or per-visitor namespaced. Whichever is chosen, it is a public
  listener with tokens and it gets the same treatment as any production deployment.
• an enqueue button, so a visitor sees a job appear and move
• ideally reachable from the landing page beside the server fold (#821)

Sequenced after the front-door work, not before: a demo that showcases a positioning nobody has
fixed yet showcases the wrong thing.

Security and cost are the real constraints, and they belong in the issue rather than in a
retrospective. A public endpoint that runs arbitrary submitted work is not a demo, it is a
compute donation — so the task set is fixed and the enqueue path is a trigger with a hard rate
limit (#847), not an open producer door.

Start with the issue's sequencing against the front-door work in #821 and the rate-limit constraint in #847. Define the hosted flexiq-server, dashboard, seeded job states, enqueue trigger, access model, and reset or namespace behavior before locating implementation entry points. Done means a public, secured demo shows jobs moving without accepting arbitrary work or exposing an uncontrolled production deployment.