Connection-owned capability descriptor to fail-fast on unsupported SQL constructs

[JJJ]

Follow-up from the #220 dialect audit. The audit's recommendation was not to build a full
dialect/rendering seam in 3.x (deferred to 4.0), but it did identify a smaller, useful step:
a connection-owned capability descriptor - a fail-fast/warn check, not a renderer.

Idea

A small descriptor owned by the connection (product, version, engine, supported cast targets,
regex family, tuple-IN support, etc.) that BerlinDB can consult to reject or warn when a
query or DDL uses a construct the live server can't support - rather than emitting SQL that
errors at runtime on an older/other engine.

Scope guardrails (from the audit)

• Not a SQL renderer and not a dialect abstraction - that is the 4.0 adapter-owned
  seam. This is only a capability description + guard.
• Lives on the connection/adapter (area: Database/Adapters), read from the live server where
  possible, with a conservative static fallback.
• Complements Audit: cross-engine SQL compatibility (MySQL/MariaDB dialect assumptions across generated SQL) #220's other follow-up (version floor + CI): CI proves the floor; the descriptor
  guards at runtime above it.

Deferring the real rendering seam to 4.0 is intentional; this is the inline 3.x step. See #220.

[JJJ]

Design note + defer (revisit when a concrete consumer exists)

Discussed; deferring. The capability descriptor is a runtime fail-fast/warn - a DX layer,
not a correctness need. The real de-risker for cross-engine compatibility is #230 (document the
version floor + run CI on both MySQL and MariaDB), which proves compatibility at development
time instead of guessing it at runtime. Per the #220 audit, BerlinDB's SQL is already largely
portable; the only real failure mode ("modern construct on too-old a server") is what #230
catches.

Decisive tell: nothing would consume it today. The version-sensitive decisions that already
exist (descending indexes, row formats, the CURRENT_TIMESTAMP DATETIME default) just emit and
let the server handle it - none branch on server identity. Adding version() / is_mariadb()
now would be an unused, speculative API. YAGNI: wait for the first real consumer (a concrete
cryptic-error report, or the 4.0 dialect seam).

Plan recorded for when we DO build it (so it doesn't sprawl)

• Vend an object; don't pile methods on Connection. One addition -
  Connection::get_<name>(): <Object> - and all server identity + capability decisions accrue
  inside that object, never back on the interface (the balloon stays contained). Same
  value-object/DI move as the Presets\Column\Context refactor (Save-side 'not provided' sentinel: distinguish an omitted column from an explicit null on write #233).
• Centralize the decisions; don't scatter is_mariadb(). version() / is_mariadb() are
  low-level facts INTERNAL to the object; call sites ask ONE semantic question
  (...->supports_row_value_in()), and the object owns the branch - no if ( is_mariadb() && version_compare(...) ) sprinkled across Column/Index/Func/Tuple.
• Warn-only, never throw - fail-closed risks breaking working sites on a bad probe.
• Name it in context, not in a vacuum. ServerInfo vs Capabilities vs a Server + info
  split depends on the surrounding types at build time (e.g. whether a Server object also
  exists, and whether caps attach to it or to Connection).
• Not a renderer/dialect seam - that stays the 4.0 work (Audit: cross-engine SQL compatibility (MySQL/MariaDB dialect assumptions across generated SQL) #220). This is capability
  description + guard only.

Adjacent (aspirational, not this issue): a modern from-scratch wpdb-style layer and
horizontal-scaling (LudicrousDB/HyperDB) awareness are both Connection-adapter concerns in
BerlinDB's model - consumed via a new Adapters/ implementation of Interfaces/Connection,
not owned in core. A read-vs-write intent hint on the connection (so a replica-aware adapter can
route) would be the scoped, useful step there - its own future issue.