feat(storage): add PostgreSQL backend for enterprise deployments

[Monst3rSec]

Summary

Closes #5

Adds PostgreSQL as an alternative storage backend for enterprise deployments requiring shared database access, connection pooling, and higher concurrency.

• New src/storage/postgres.rs: full Store trait implementation backed by an r2d2_postgres connection pool; auto-migrates schema on connect; gated behind --features postgres to keep the default binary lean
• New open_store() dispatcher in storage/mod.rs: routes to PostgresStore when OCEAN_POSTGRES_URL env var is set, falls back to SqliteStore otherwise
• AppState.store changed from Arc<SqliteStore> → Arc<dyn Store> so both backends work with the REST API and CLI without further changes
• OCEAN_POSTGRES_POOL_SIZE env var controls pool size (default 10)

Existing SQLite behaviour is completely unchanged when the postgres feature is not enabled or OCEAN_POSTGRES_URL is unset.

Usage

# Default (SQLite — unchanged)
cargo build
ocean observe mock.test

# PostgreSQL backend
cargo build --features postgres
export OCEAN_POSTGRES_URL="postgres://user:pass@host:5432/ocean?sslmode=require"
export OCEAN_POSTGRES_POOL_SIZE=10   # optional, default 10
ocean observe mock.test
ocean serve --port 8080

Test plan

• cargo test passes (SQLite path — default, no env vars needed)
• cargo test --features postgres compiles without errors
• With OCEAN_POSTGRES_URL pointing to a live instance, integration tests in src/storage/postgres.rs pass (auto-skip when env var is unset)
• ocean serve works with PostgreSQL storage (OCEAN_POSTGRES_URL set)
• Evidence pruning works correctly via prune_evidence()
• Connection pool handles concurrent API requests under load
• Graceful error returned when OCEAN_POSTGRES_URL is set but unreachable

🤖 Generated with Claude Code

[Monst3rSec]

Hi @p4gs,

Please review and guide me to contribute more to this projects.

Thanks.

[p4gs]

Thanks for this, and a real apology — five months without a response on a well-formed contribution is not the standard we want to hold.

Some concrete signal rather than more silence:

• Your branch is still current. src/storage/ has had zero commits since you opened this, so the trait surface you built against hasn't drifted. GitHub reports the PR as mergeable with no conflicts.
• CI never ran here — that's a workflow-trigger gap on our side, not anything you did. I'm kicking it now so you get real results.
• Heads up on what you'll see: main itself is currently red on CI / Fuzz / Vulnerability Scan / Secret Scan for reasons that predate and are unrelated to this PR. If those same jobs fail on your branch, that's inherited from main, not caused by your changes. Judge this PR on the jobs that differ from the main baseline.

Next step is an architecture review on our side — a second storage backend is a real interface commitment, so that's our call to make and we owe you a decision either way.