Say in the architecture what the decoder trait became

§3.2 sketches a RawDecoder over a seekable reader, and the crate map
named it. FR-RAW-2 was built in 0.15.0 as dr_decode::Decoder over bytes
(core/dr-decode/src/decoder.rs:33): the decoder states how much it needs
and where its preview is, and the storage layer fetches it. The sketch
stays as the argument for four entry points; a note under it says what
shipped, and the crate map uses the built name.

docs/dev/architecture.md

@@ -52,7 +52,7 @@ darkroom/
 │   ├── dr-types        SourceRef, ImageId, VersionId, ParamValue — shared vocabulary
 │   ├── dr-catalog      SQLite index, scan, query, metadata
 │   ├── dr-sidecar      the authoritative edit store (§6.12)
-│   ├── dr-decode       RawDecoder trait, rawler impl, embedded-preview extraction
+│   ├── dr-decode       Decoder trait (§3.2), rawler impl, embedded-preview extraction
 │   ├── dr-pipeline     Operation trait, descriptors, edit graph, registry
 │   ├── dr-gpu          wgpu device, tile scheduler, WGSL shaders, mask rasteriser
 │   ├── dr-colour       lcms2 bindings, camera profiles, working-space transforms
@@ -132,6 +132,15 @@ Four separate entry points because the caller's needs differ sharply by phase. C
 `RawImage` carries CFA-pattern sensor data plus black/white levels and camera colour matrices — it
 is *not* demosaiced. Demosaic is a GPU pipeline stage (§5.2).
 
+> **As built (FR-RAW-2, 0.15.0).** The trait is `dr_decode::Decoder`, and it takes bytes rather
+> than a reader: `header_bytes` says how much of a file metadata needs, `metadata` and
+> `orientation` read it, `locate_preview` says where the embedded preview sits so the caller's
+> storage can fetch that range, and `preview` and `decode` take the bytes fetched. The split this
+> section argues for survives; what moved is who reads the file, which is the storage layer
+> (§3.1's `read_range`), not the decoder. `dr_decode::Rawler` is the one implementation, and only
+> the places that start a job name `dr_decode::default()`; everything below them takes a
+> `&dyn Decoder`.
+
 ### 3.3 Operation and descriptors
 
 The develop pipeline is a sequence of operations with a uniform interface. Polymorphism is by