Make README project status visual and concise

Author: KSemenenko

AGENTS.md

@@ -458,7 +458,7 @@ For changes outside existing owner authorization, obtain direction before changi
 - Other chats' plans, progress, requests and concurrent changes MUST NOT expand an agent's task or redirect its implementation. Preserve their work and leave their tasks to their owners (owner correction 2026-10-03).
 - Repairs and verification MUST stay within the assigned task. Report an unrelated failure to the owner without taking over its implementation; direct user instructions remain authoritative (owner correction 2026-10-03).
 - Frequent concise Ukrainian progress stating completed work, remaining work and real blockers.
-- The root README MUST introduce KeyLoad as a product: its purpose, connected data models, agent use cases, getting started, and direct credits to the projects it actually uses. Keep dependency versions in their canonical manifests and link to detailed technical documentation (owner correction 2026-10-03). The README MUST read as an engaging, plain-language product page that a newcomer understands on first read and can act on: a clear problem/pitch, how it works, a runnable quick start, real SDK/SQL/MCP examples, an honest available-versus-in-progress status and a repository map for contributors. Internal specification jargon belongs in the linked docs, not the README. Every rewrite MUST retain all existing credits and add any actually used project that is missing (repeated owner correction 2026-10-04).
+- The root README MUST introduce KeyLoad as a product: its purpose, connected data models, agent use cases, getting started, and direct credits to the projects it actually uses. Keep dependency versions in their canonical manifests and link to detailed technical documentation (owner correction 2026-10-03). The README MUST read as an engaging, plain-language product page that a newcomer understands on first read and can act on: a clear problem/pitch, how it works, a runnable quick start, real SDK/SQL/MCP examples, an honest available-versus-in-progress status and a repository map for contributors. Internal specification jargon belongs in the linked docs, not the README. Every rewrite MUST retain all existing credits and add any actually used project that is missing (repeated owner correction 2026-10-04). Owner correction 2026-10-09 requires a compact, visual README: Project status MUST show what each workstream delivers, why it matters, its actual state and what remains in a readable table, with a Mermaid stage flow where helpful. Replace repetitive prose with concise tables or diagrams and links to canonical detail; preserve honest qualification limits and do not invent completion percentages or schedules.
 - Shared-checkout work that preserves unrelated changes and completes authorized delivery.
 - Real Docker/Aspire multi-node comparisons using the same data, oracle and workload contract.
 - All published test results and chart values MUST come from JSON produced by successful GitHub Actions runs. Include raw GitHub JSON links, measured source SHA, options, topology and acknowledgement/read guarantees. Missing or unsupported measurements MUST remain unavailable; never invent winners, zeros or sample performance values.