docs: update architecture and plan for tree inspector UI

Record the viewer-registry decision and refresh the extract/web
descriptions and repo layout.

docs/decisions.md

@@ -111,4 +111,21 @@ small amount of client state (search + mod).
 
 **Alternatives considered:** Next.js (heavier than needed for a client-only
 tool); Redux Toolkit (more boilerplate than warranted); CSS Modules (no
-utility styling).
+utility styling).
+
+## D10 — Object inspection via a viewer registry
+
+**Decision:** The mod page shows a containment-tree sidebar (mirroring how TTS
+nests objects) and an inspector pane. The inspector resolves a per-class viewer
+from a registry (`registerViewer` / `resolveViewer`), falling back to a
+`DefaultViewer` that renders an object's raw fields.
+
+**Context:** The user wants to visualize objects in a save. A flat list of all
+objects and assets is hard to navigate, so the UI was reworked around a tree
+and a selected-object inspector. Custom viewers per object class (`Card`,
+`Bag`, ...) are expected later; a registry keeps that extension point explicit
+without coupling the page to any one viewer.
+
+**Alternatives considered:** A single monolithic inspector component. Rejected —
+would grow unboundedly as per-class viewers are added; the registry keeps each
+viewer isolated and swappable.