docs(examples): add live overview page for all job types

[RapidPoseidon]

What

Adds docs/examples/index.md — an overview page on the Examples tab showing every job type the SDK can create as a scrollable gallery of live phones. Each card is a real campaign you can try in place, with a link to the example behind it for the code. The headings feed Material's table of contents, so the right rail jumps between modalities rather than making you scroll.

Seven cards: Classification, Comparison, Locate, Draw, Select Words, Free Text, Ranking.

The page is wired into nav and into the llmstxt-md Examples section.

Load cost

Seven live rapids apps is not free, so this was measured rather than assumed. One phone is 43 requests / ~870 KB / ~0.6 s. All seven booting eagerly: ~340 requests, ~7.4 MB.

Two mitigations in docs/js/preview-embed.js:

• data-preview-lazy — the iframe ships with no src; an IntersectionObserver fills it in 150 px before the phone enters view. First paint boots only the 2–4 phones actually on screen.
• Serialised boots — lazy alone still cost 4.6 MB up front. Phones entering the viewport in the same frame all request the same rapids bundle before any of them has populated the HTTP cache, so the page pays for that bundle once per phone. Booting one at a time (waiting on load + 500 ms, with a 3 s cap so a stalled phone can't block the queue) lets everyone after the first read it from cache.

	requests	first paint	total
eager	~340	~4.6 MB	~7.4 MB
lazy + serialised	~340	~3.5 MB	~6.0 MB

That's the floor for auto-playing embeds, since each phone is a full Next.js app. A click-to-load facade (static poster + "try it" overlay) would take first paint to near zero at the cost of one click before interaction — happy to switch if that trade reads better.

Both the existing embeds (starting page, quickstart) keep their current eager behaviour; lazy is opt-in per wrapper.

The preview campaigns

Each card points at a dedicated SDK DOCS examples <type> order that is created but never run, so it stays in preview state, collects no responses, and is never billed — the same setup as the four previews already on the starting page.

selections=[LabelingSelection(amount=3)] is passed explicitly when creating them. Without it, compare / classify / ranking inherit a default validation set and the backend puts two unrelated qualification rapids (a red panda, a sentiment question) in front of the task the card is meant to demonstrate. Locate, draw, select words and free text have no default set and are unaffected.

Card	Campaign
Classification	cmp_1SCZysSRxUHIJ5
Comparison	cmp_1SCZyXpfpHFbmd
Locate	cmp_1SCZhvwq8dKVfQ
Draw	cmp_1SCZiFks5AUIMi
Select Words	cmp_1SCZiZoHgeFf8t
Free Text	cmp_1SCZitM8vyAoTC
Ranking	cmp_1SCZzu6YH6ncAs

Worth a look before merging: these are owned by poseidon@rapidata.ai, whereas the four starting-page previews are owned by lino@rapidata.ai / org_1PHx4XH5QQEGY6. They render fine (the preview endpoint is public), but if that service account is ever cleaned up the previews go with it. Say the word and I'll recreate them under the same account as the existing ones.

Verified

• uv run --group docs mkdocs build clean (no new warnings)
• All seven phones boot and open on their own task; Refresh yields a fresh one
• Lazy gating confirmed: 4 booted / 3 idle on first paint at 1400×1000, 2 booted at 390×844
• Checked at desktop (two columns) and mobile (one column) widths

The first commit on this branch is the earlier tabbed-set version, kept in history for comparison.

🔗 Session: https://poseidon.rapidata.internal/chat/session-52146939

🤖 Generated with Claude Code