What

Audit and document the support status and default behavior of every database_system backend and ecosystem integration option.

Part of kcenon/common_system#684.

Current read-only analysis observed a potential consumer-facing mismatch:

Why

Users can get different behavior depending on whether they build directly with CMake or consume via vcpkg. Experimental backends and optional ecosystem integrations need an explicit feature matrix so consumers know what is production-ready, what is optional, and what is still experimental.

Where

• vcpkg.json
• cmake/options.cmake
• cmake/dependencies.cmake
• README.md
• docs/BACKENDS.md
• docs/advanced/CURRENT_STATE.md
• legacy_include/**

How

Approach

1. Build a matrix covering PostgreSQL, SQLite, MongoDB, Redis, thread integration, monitoring integration, container integration, OpenSSL, and legacy include shims.
2. For each row, document CMake default, vcpkg feature/default status, support level, and required verification command.
3. Decide whether CMake and vcpkg defaults should be aligned or explicitly documented as intentionally different.
4. Add lifecycle/removal notes for legacy include shims if missing.
5. Open targeted follow-ups for any experimental backend that is accidentally presented as production-ready.

Acceptance Criteria

• Backend/integration feature matrix committed to docs and linked from README
• CMake defaults and vcpkg defaults are either aligned or explicitly documented as intentionally different
• MongoDB and Redis experimental status is visible wherever the features are introduced
• Legacy include shim lifecycle is documented with a removal target or retention policy
• [EPIC] Ecosystem hardening follow-up from 2026-05-21 analysis common_system#684 receives the final database summary

Verification

• Configure at least the default CMake path and the vcpkg default feature path
• Verify PostgreSQL default path still works or document any external-service requirement
• Verify docs mention every backend exposed in vcpkg.json