ONE SOURCE MULTI USE: extract the pgcrypto KV credential registry into a standalone importable package

[seonghobae]

Why (proven independent value, currently duplicated)

The org's runtime-config/secrets rule is "KV, not env": services must read credentials from an encrypted credential registry (get_credential / register_credential), never os.getenv / process.env at request time. That registry is a proven, independently-valuable component that today is described as a pattern to copy rather than a shared dependency:

• contextual-orchestrator is the documented reference implementation: credentials.py / kv_config.py with an InMemoryCredentialBackend default and a pgcrypto-encrypted PostgresCredentialBackend (selected via CONTEXTUAL_ORCHESTRATOR_KV_BACKEND).
• gyeot AGENTS.md explicitly says "reuse that pattern … unless a dedicated KV is adopted" and records a known deviation to migrate (server/ still reads AUTH_TOKEN_SECRET / DATABASE_URL from process.env).
• keyverse resolves all config/secrets from a KV/DB store (app/bootstrap.py → app/kv_store.py), naruon injects AUTH_SESSION_HMAC_SECRET/ENCRYPTION_KEY with no code defaults, semantic-data-portal resolves SDP_CONNECTOR_SECRET_* references, and contextual-orchestrator consumers (gyeot, scopeweave) all need the same primitive.

Each repo reimplementing or hand-copying this is exactly the drift the ONE SOURCE MULTI USE strategy exists to prevent, and it is the one component the org's own docs already point at consolidating ("a dedicated KV").

Domain viability (per the ONE SOURCE MULTI USE gate)

• Bounded domain: credential storage/retrieval only — get_credential(name) / register_credential(name, value); no CWL-business coupling.
• Stable, minimal interface already proven in production use by contextual-orchestrator.
• Pluggable backends (InMemoryCredentialBackend, pgcrypto PostgresCredentialBackend), so a consumer with Postgres (keyverse, naruon, pg-erd-cloud, gyeot all run Postgres) reuses the encrypted backend while tests use in-memory.
• General value beyond CWL: an at-rest-encrypted, backend-pluggable credential registry is broadly reusable — a genuine standalone product surface, not a CWL-only helper.
• Permissive-license clean: the reference impl is stdlib + psycopg/pgcrypto; no copyleft.

Proposal

Extract the reference implementation into a standalone importable package (working name cwl-kv), consumable two ways per the org's standalone-AND-submodule convention: a published/importable Python package and a vendorable submodule.

Migration path (incremental, non-breaking):

1. Lift credentials.py + kv_config.py (+ tests) from contextual-orchestrator into the new package; keep the exact get_credential/register_credential surface and the two backends.
2. contextual-orchestrator re-exports from the package (no API change for its callers).
3. Replace per-repo copies/patterns with the dependency one repo at a time; resolve gyeot's documented process.env deviation by adopting it.
4. Keep bootstrap-into-KV transport (env → KV at boot) unchanged; only the runtime read path is centralized.

Grounding: standard secrets-management / DRY practice (a single audited credential path is easier to harden than N copies), with at-rest encryption via Postgres pgcrypto.

Decision requested (owner)

This issue is the domain-viability proposal step; the actual split needs an owner call on (a) new repo cwl-kv under the org, and (b) distribution (PyPI vs. submodule-only). Once decided I can do the lift + per-repo migration PRs. Flagging for Project #1 triage.