feat(storage): add Cassandra backend (per --backend help text)

[quinnypig]

What this is

A new cassandra storage backend, gated behind a cassandra cargo feature. Registers a Bootstrapper via the same inventory plugin path the postgres backend uses. Every trait method returns OpError::Internal pointing the caller at --backend postgres.

It does not implement Cassandra. Nothing in this repository implements Cassandra. That is the entire point of the PR.

Why this exists

The codebase references Cassandra in three places:

1. crates/bin/src/cmd_init.rs:19 — the --backend clap help:

   /// Storage backend (postgres, cassandra, etc.) (default: postgres)
   

2. crates/storage/src/server_components.rs:95:

   /// Backend name (e.g., "postgres", "cassandra")
   

3. crates/storage/src/bootstrapper.rs:7:

   //! `CREATE DATABASE` is PostgreSQL DDL vs `CREATE KEYSPACE` for Cassandra
   

A user who reads the help text and runs extenddb init --backend cassandra against a v0.1.0 binary sees:

Error: Internal("Unknown backend: cassandra. Available backends: postgres")

A fair description, but it contradicts the documentation the user was just reading. This PR replaces that error with a different error that at least acknowledges the documentation.

What's in the diff

• crates/storage-cassandra/ as a new workspace member.
• 15 async Bootstrapper methods. Each returns OpError::Internal with the method name and a sentence pointing back at --backend postgres. The 4 sync methods return placeholder strings like "<no cassandra keyspace>" and "cassandra://placeholder/please-implement".
• A BackendRegistration for "cassandra" submitted via inventory::submit!, mirroring the postgres backend.
• A cassandra = ["extenddb-storage-cassandra"] feature in crates/bin/Cargo.toml. Default features are unchanged.

What's not in the diff

• Cassandra. Not implemented.
• The other registrations a real backend needs (OperationsEngineRegistration, StorageConfigRegistration, SettingsStoreRegistration, DiagnosticsStoreRegistration, ServerComponentsRegistration). The implementation depth in this PR matches the depth of investment Cassandra has received elsewhere in this codebase to date.
• Changes to crates/bin/src/config.rs, which hard-references the postgres config type regardless of feature flags. Disentangling that is left to whoever actually implements Cassandra.

Behavior change

Before:

$ extenddb init --backend cassandra
Error: Internal("Unknown backend: cassandra. Available backends: postgres")

After (built with --features cassandra):

$ extenddb init --backend cassandra
Error: Internal("is_catalog_initialized: Cassandra backend is referenced
in `extenddb init --backend` help text and in the bootstrapper trait
documentation but has no implementation. Use `--backend postgres`, or
open an issue requesting that the Cassandra references be removed from
the codebase pending an actual implementation.")

Alternative

If the answer is "remove the Cassandra references from the codebase" rather than "add a backend stub," I can scope this to a one-line update to crates/bin/src/cmd_init.rs:19 plus the two analogous edits. Pick whichever is funnier.

Trademark note

The README is careful to point out that ExtendDB is not Amazon DynamoDB and that DynamoDB is a trademark of Amazon.com, Inc. Cassandra is a trademark of the Apache Software Foundation. I have nothing else to add. I just wanted to be on the record about having noticed.

[jcshepherd]

Hi Corey - Thanks for the catch. We'd actually prefer at this point to correct (remove) the code references to Apache Cassandra at this point, rather than provide a non-functional stub implementation. If you want to alter this PR to do that, that'd be great, or I'm happy to take care of it on this end. Thanks for pointing out the confusion.