fix(browse): propagate writable bit into tree nodes

Root cause of "I'm root admin but the editor says read-only."

loader.js parses the listing JSON and stamps `writable` onto the raw
entry. tree.js:newNode() then copies every other field (name, url,
isDir, size, modTime, ext, handle, virtual …) into the tree node —
but dropped `writable`. So `node.writable` was always undefined and
`canSave(node)` short-circuited to false, mounting the YAML and
markdown editors read-only even for an elevated admin where the
server had correctly stamped writable=true.

Symptom: red banner / read-only mode regardless of admin status.
Server-side log line was correct (elevated=true active_admin=true
chain_admin_level=0); the bit just never reached the editor.

One-line fix: include `writable: !!raw.writable` alongside `virtual`
in the tree-node initialiser. Verified end-to-end against the live
bitnest fixture — every entry now carries the bit through.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

browse/js/tree.js

@@ -43,7 +43,13 @@
             // True when this entry was synthesized client-side (e.g.
             // canonical project folders that don't exist on disk yet).
             // Rendered with a muted style + an "(empty)" hint.
-            virtual: !!raw.virtual
+            virtual: !!raw.virtual,
+            // Server-computed write authority. Editors (preview-yaml,
+            // preview-markdown) consult this via canSave() to decide
+            // whether to mount read-only. Dropping the field here
+            // silently makes every node read-only — the actual root
+            // cause behind "I'm admin but the editor says read-only".
+            writable: !!raw.writable
         };
         state.nodes.set(id, node);
         return node;