feat: add durable store record serialization

docs/contracts.md

@@ -249,3 +249,10 @@ with a factory that returns a fresh store. The harness covers readiness,
 idempotent migration, core save/read/query behavior, transaction rollback,
 outbox ordering, and diagnostics that expose counts without raw factor or
 profile values.
+
+`user_engine.store_records` defines the JSONB serialization contract for the
+generic record table. `store_record_for` turns supported domain dataclasses
+into `StoreRecord` envelopes with deterministic keys and index metadata, while
+`domain_record_from_store_record` restores those payloads to domain objects.
+These payloads are durable state and may contain sensitive values, so they must
+not be emitted as diagnostics.

docs/development.md

@@ -17,6 +17,7 @@ src/user_engine/
   ports.py     adapter protocols for identity, authorization, events, audit,
                membership export, application bindings, and secrets
   service.py   headless service API for the isolated MVP
+  store_records.py JSON-safe durable-store record serialization
   testing/     local fixtures for tests and examples
 tests/         standard-library unittest suite
 ```

docs/postgres-durable-store-consumer-requirements.md

@@ -289,6 +289,18 @@ bootstrap schema, and `user_engine.testing.store_conformance` exposes a
 reusable harness that future adapters can run with their own store factory.
 The standard local suite runs that harness against `InMemoryUserEngineStore`.
 
+USER-WP-0017 adds the provider-neutral serialization layer. Future Postgres
+adapters should use `user_engine.store_records.store_record_for` before writing
+to `user_engine_records` and `domain_record_from_store_record` after reading
+JSONB payloads back. The `StoreRecord` envelope maps directly to the generic
+record table columns: `record_type`, `record_key`, `tenant`, `user_id`,
+`application_id`, `scope_type`, `scope_id`, and `payload`.
+
+Durable payloads are raw state, not diagnostics. They can include factor
+values, profile values, prepared-account matches, and access-profile defaults.
+Adapters must avoid logging payloads and should use `record_counts` or other
+redacted diagnostics for observability.
+
 Likely future follow-up work should be:
 
 - Add a Postgres adapter behind the existing store boundary.