Extract PostgreSQL and SQLite implementations into a SQLx backend crate

[leseb]

Parent epic: #1257

Depends on #1258 and #1259.

Summary

Extract PostgreSQL and SQLite persistence implementations into a dedicated, unpublished Praxis AI SQLx backend crate while preserving the existing production defaults, security controls, schemas, and feature matrix.

These implementations encode OpenAI Responses, Conversations, owner isolation, and MCP approval semantics. They remain AI-owned rather than moving into Praxis core.

Scope

• Move PostgreSQL and SQLite store implementations, pool configuration, schema validation/migration, and backend-specific tests into the backend crate.
• Mark the package publish = false, document it as internal and unstable, and keep it in the Praxis AI workspace.
• Move PostgreSQL URL, TLS, certificate-authentication, and table-identifier logic with the PostgreSQL implementation.
• Preserve the certificate-authentication compliance profile delivered by Define and enforce the PostgreSQL cryptographic boundary #1217.
• Keep PostgreSQL and SQLite features independently selectable and combinable.
• Register backend factories through the lifecycle interface rather than importing concrete stores from filters.
• Preserve default praxis-ai-proxy behavior: PostgreSQL remains enabled by default and SQLite remains explicit.
• Preserve all ownership, transactional approval, conversation-item ordering, and concurrent-update guarantees.

Acceptance criteria

• The SQLx backend crate implements the shared contract tests for PostgreSQL and SQLite.
• The backend package sets publish = false and is not included in any publishing workflow.
• PostgreSQL-only, SQLite-only, and combined builds compile and pass their relevant tests.
• Default praxis-ai-proxy contains PostgreSQL support and excludes libsqlite3-sys.
• SQLite is present only when explicitly selected.
• PostgreSQL verified TLS and certificate-authentication tests continue to pass.
• No request-path filter imports a concrete SQL store or SQLx type.
• Persisted schema and migration behavior remain unchanged.

Non-goals

• Changing database schemas.
• Adding another database implementation.
• Implementing a remote HTTPS store backend.
• Publishing the backend crate or supporting it as an external Rust API.
• Moving AI-specific records, schemas, transactions, or SQL implementations into Praxis core.