Docs: improve discoverability of canvas, dashboard, retries, and prefork to preempt repeated misframed audits

[pratyush618]

Context

A recent external review of taskito claimed several capabilities were missing that, in fact, are already implemented and shipped:

Reviewer claim	Reality
"No canvas/workflows — no chain, group, or chord"	Implemented. chain, group, chord exported from the top-level package; full workflow DSL in py_src/taskito/workflows/.
"No Flower-like dashboard"	Implemented. taskito dashboard --app myapp:queue serves a built-in monitoring UI (py_src/taskito/dashboard/, dashboard/src/ for the React app).
"No retry backoff/jitter or per-exception max retries"	Implemented. @queue.task(max_retries=..., retry_backoff=..., retry_on=[...], dont_retry_on=[...]).
"Lacks soft timeouts"	Implemented. current_job.check_timeout() cooperative pattern.
"GIL bottleneck — no escape hatch"	Mitigated. pool="prefork" spawns child processes with independent GILs; surfaced in CLI as --pool prefork in #80.

These are all in the README features list and/or the docs site, but the reviewer still missed them. The pattern suggests the discoverability is too low — feature names live in a flat bullet list without anchored headings, and there is no single "what taskito already does" page that an external auditor would land on.

Goal

Restructure the README and a top-level docs page so that a casual reader (or external reviewer browsing the repo for ten minutes) cannot miss these features. The signal we want: "if you think feature X is missing, the README's table of contents will catch your eye before you start writing the audit."

Proposed changes

1. README — split the flat features bullet list into named subsections with anchor links, e.g.:
   • Reliability: retries (backoff + jitter + per-exception), timeouts, dead-letter queue, idempotent enqueue.
   • Workflows: chain / group / chord with one-line code samples.
   • Concurrency: thread pool (default, I/O-bound) vs. prefork pool (CPU-bound, link to docs/guide/execution/prefork.md), with a one-line explanation of when to pick which.
   • Observability: built-in dashboard, events system, webhooks, Prometheus, OpenTelemetry, structured logging.
2. docs site — add a top-level "Capabilities at a glance" page under docs/ that mirrors the README subsections and is the first hit from the docs index. Each row links to the in-depth guide.
3. Comparison table at bottom of README — extend the existing comparison row set to include "Built-in dashboard", "Task chaining", "Prefork pool / CPU parallelism" so the table itself answers the common-misperception questions.
4. CLI help — taskito --help should list all subcommands with one-line summaries that name the user-visible features (it currently does, but a verification pass to confirm parity with the README is worthwhile).

Acceptance criteria

• A reader who reads only the README's TOC + one comparison table can correctly answer: does taskito have chain/group/chord? a dashboard? retry backoff? a CPU-parallel pool?
• Docs index page docs/index.md (or equivalent) has a link to "Capabilities at a glance" within the first screen of content.
• Each feature subsection has a one-line code sample and a link to the deep-dive guide.
• No code changes required outside README.md and docs/.

Why this matters

External audits that mistakenly claim missing features generate noise in issues, social media, and review threads. Each round costs maintainers time to refute. Closing the discoverability gap is a one-time fix that preempts the recurring pattern.