Clients: client-selection guide + capability/version matrix

[robfrank]

Parent: #4894

Motivation

Serves "two client families by persona; ship a decision guide instead of unifying specs." Without this, users will default to whichever client they find first (likely the hand-written Java grpc-client, since it's the only mature one today) rather than the one that actually fits their use case.

Proposed design

• New page in arcadedb-docs (location TBD — verify the docs repo/site structure during implementation, likely alongside existing driver/client documentation) answering: "HTTP (universal, admin+data+observability, works everywhere fetch works) vs. gRPC (performance data-plane, streaming/bulk ingest, backend languages + Connect-ES for JS)."
• Per-client README for each package produced by this Epic, each following a consistent template (install, auth, quickstart, "which client is this" cross-link).
• Capability/version matrix: a table of {client, language, transport, generated-from, current version, server-release compatibility, streaming support} kept up to date by the release automation issue (ideally auto-generated as part of its release pipeline rather than hand-maintained, to avoid the matrix itself drifting).

Acceptance criteria

• Decision guide published and linked from the main ArcadeDB docs navigation.
• Every client package from this Epic has a README following the shared template.
• Capability matrix exists and reflects the actual shipped clients (spot-check against the release automation issue's output).

Dependencies

Depends on the thin TS client, REST fan-out, Connect-ES, and per-language gRPC client issues existing (needs real clients to document) and benefits from the release automation issue (auto-generating the matrix rather than hand-maintaining it).

Effort estimate

S — primarily writing, but blocked until enough clients exist to compare.