Decide NFR-R8: no CPU pipeline, a degraded mode instead

NFR-R8 carried the words "decide explicitly" for six weeks, asking
whether v1 has a full CPU render path or whether "CPU fallback" means
staging only. The viewer had already answered it: with no adapter it
opens the library on embedded previews and cached proxies, keeps every
catalog edit available, and withholds develop and export. That is the
degraded mode, it is now the requirement, and NFR-RES-2 no longer
promises a fallback render path that was never going to be built.

docs/requirements.md

@@ -1704,11 +1704,14 @@ loss mid-render.
 available, the app starts in a stated degraded mode with defined capability limits rather than
 failing to launch.
 
-*This requires reconciling ARCH §6.4 and NFR-RES-2:* ARCH §6.4 says the GPU path is primary rather than an
-optimisation, while NFR-RES-2 assumes a CPU fallback on allocation failure. **Decide explicitly**
-whether v1 includes a full CPU pipeline, or whether "CPU fallback" means only tile-spill staging
-with no independent CPU render path. The latter is recommended; the former is a second full
-implementation.
+**Decided 2026-09-19: there is no CPU render pipeline.** The degraded mode is the one the
+viewer already has (`dr_ui::shared_gpu` returning `None`): the library opens, the grid and the
+culling views run on embedded previews and cached proxies, metadata, ratings and collections are
+fully editable, and develop and export are unavailable and say so. "CPU fallback" in this
+document means nothing more than staging through host memory when GPU memory is short; it never
+means a second implementation of the operations. ARCH §6.4 stands as written, and NFR-RES-2's
+fallback clause has been reworded to match. A second full pipeline was the alternative, and it was
+declined for the reason ARCH §6.4 gives: the GPU path is the product, not an optimisation of it.
 
 ### 4.3 Resource behaviour
 
@@ -1716,7 +1719,9 @@ implementation.
 size and image count. Caches are evictable under pressure.
 
 **NFR-RES-2 — GPU memory.** The pipeline shall handle images larger than available GPU memory by
-tiling. GPU memory headroom is configurable, with a CPU fallback path if allocation fails.
+tiling. GPU memory headroom is configurable. Where an allocation fails, work is staged through host
+memory or refused with a typed error (`GpuError::TooLarge`) — never rendered by a CPU pipeline,
+which does not exist (NFR-R8).
 
 **NFR-RES-3 — Mobile power.** On Android the app shall not render continuously when idle. Battery
 and thermal behaviour are first-class concerns; background sync respects metered-connection and