Consider depending on elide_core in nvisy-postgres to dedupe mirrored enums (RasterPolicy/RasterMode)

[martsokha]

Problem

Some persisted enums in nvisy-postgres mirror engine concepts from elide, requiring a hand-written mapping layer. The clearest case:

• nvisy_postgres::types::RasterPolicy (Auto/Always/Never) duplicates elide_pipeline::RasterMode, mapped by hand in crates/nvisy-server/src/service/detection/worker.rs:417 (raster_mode_of).

Today nvisy-postgres has no elide dependency — the mapping lives in nvisy-server, which sits between the two. The question is whether nvisy-postgres should depend on an elide crate (e.g. elide_core) directly and reuse the engine type instead of redefining it.

Considerations

For:

• Removes the duplicate enum + the manual mapping; one source of truth for the raster/OCR concept.
• Changes to the engine's enum propagate automatically.

Against (weigh carefully):

• Layering. nvisy-postgres is the persistence layer; pulling a pipeline/engine crate into it inverts the dependency direction (persistence depending on the engine) and couples the DB schema to engine releases. Today elide is only a nvisy-server dependency.
• The DB type needs traits the engine type may not derive — DbEnum (ExistingTypePath), diesel (de)serialization, the #[db_rename] values matching the SQL enum. If RasterMode doesn't derive these (and it shouldn't, to stay storage-agnostic), we'd still need a newtype/wrapper in postgres, which brings back much of the boilerplate.
• Persistence stability vs. engine churn. A stored enum's variants are a schema contract (there's a RASTER/OCR SQL enum). Coupling it to an engine type that can add/rename variants risks migrations driven by engine changes.
• Build/dependency weight in the postgres crate.

Suggested scope

• Inventory which persisted enums actually mirror elide types (start: RasterPolicy; check provider_type, and anything modality-related).
• Decide the principle: does the persistence layer own its own storage enums (current design, explicit mapping in the service layer) or reuse engine types?
• If reuse: prefer a From/TryFrom mapping kept in one place over a raw dependency, unless the engine type can cleanly satisfy the DbEnum/diesel requirements without leaking storage concerns into the engine crate.

Relates to #258 (enum boilerplate).