feat(underlay): render PDF underlays end-to-end

PDF underlays only drew their clip outline / insertion cross; the page
itself never appeared. The chain now runs: the definition's file path
resolves with the raster-image fallbacks (as stored, relative to the
drawing, basename next to the drawing — attach-time relative paths go
stale), the page rasterises through the system pdftoppm (poppler) at
150 dpi — no new crate; missing tool degrades to the outline — cached
per (path, page) including negative results, and the pixels feed the
existing image pipeline as an ImageModel: 1 underlay unit = 1 PDF inch
(px/dpi × entity scale), rotated about the insertion, fade as opacity,
the clip polygon (non-inverted) as the textured region. Draw-order,
layer visibility and per-viewport freezes ride the generic image path;
in-place edits rebuild through the shared image seed.

When the page renders, the wire path draws its frame with an interior
pick surface instead of the lone cross, so selection covers the visible
page. wasm keeps the outline placeholder (no external process).

Co-Authored-By: Claude Fable 5 <[email protected]>

src/io/mod.rs

@@ -246,6 +246,20 @@ fn resolve_raster_image_paths(doc: &mut CadDocument, base_dir: Option<&Path>) {
             }
         }
     }
+
+    // Underlay definitions (PDF/DWF/DGN) store their file the same way raster
+    // images do — resolve them with the same fallbacks so a drawing shipped
+    // next to its PDF finds it even when the stored relative path is stale.
+    for o in doc.objects.values_mut() {
+        if let ObjectType::UnderlayDefinition(def) = o {
+            if def.file_path.trim().is_empty() {
+                continue;
+            }
+            if let Some(resolved) = resolve_image_file(&def.file_path, base_dir) {
+                def.file_path = resolved;
+            }
+        }
+    }
 }
 
 /// Resolve a (possibly foreign / absolute) image path to an existing file: