feat: implement custom context separation profiles (#36)

[Archita-29]

Resolves #36

Summary

This PR implements isolated database partitioning (db_work, db_play, db_travel) to provide strict context separation across user environments, resolving cross-profile context leakage as outlined in #36.

Protocol Alignment

[x] CAP — Context Access Protocol

[x] CCP — Context Contribution Protocol

[x] CRP — Context Rectification Protocol

[ ] Identity Address

[ ] Discovery

[ ] Evidence Model

[ ] Temporal Decay

[ ] Provider Independence

[ ] Documentation

[ ] Community Health

[ ] Other: ___

Changes Made

Data Layer (src/store.mjs)
Updated internal data structures to support an optional database_partition string field across schemas.

Default fallback handles unpartitioned incoming data by routing it safely to "db_work".

Service Layer (src/service.mjs)
Ingestion: Updated ingestCaptureEvent and proposeWikiContext to extract the active partition from options/body parameters and stamp the records appropriately.

Retrieval & Isolation: Updated data retrieval methods (listCaptureEvents, listMemory, listSchemas) to strictly filter records matching the requested target partition, preventing cross-profile context pollution.

API Layer (src/server.mjs)
Added a readDatabasePartition helper utility to cleanly parse out the active profile via the custom X-Database-Partition header or the database_partition query string parameter.

Forwarded the evaluated partition into the matching service layer actions (propose, rectify, request).

Updated CORS Access-Control-Allow-Headers rules to safely permit the X-Database-Partition custom header across browser contexts.

[keepsloading]

@AYUSH-P-SINGH I've reviewed your PR. Overall the separation looks interesting, but I have to request some architectural changes.

1. Hardcoded Partitions: Currently you are falling back to "db_work" whenever a partition isn't found. This couples the identity provider codebase explicitly to a specific context profile type ("work"), which breaks the provider-independent and category-agnostic vision. Partitions shouldn't be hardcoded into the gateway logic like this.
2. Missing Implementation: In src/server.mjs, you import buildCapPacket from Memory but then you removed the API credits endpoint without explanation.
3. Storage Abstraction: The partition logic assumes a single flat store that magically understands db_work. As per our new architecture roadmap, the storage layer is migrating to SQLite. Context separation profiles should ideally be modeled in the database schema (e.g., via a profile_id linking to an identity profile), rather than hardcoding partition keys in the HTTP headers.

Please revise the partition routing logic to be dynamic and agnostic to the actual profile name (e.g., "work", "play", "travel"), and we can proceed. Thanks!