feat(files): a Files section over the caller's whole space

Until now file browsing existed only inside a project, and the two memory
stores were reachable only by the agent's tools. `#files` is the general
surface: home, both memory stores, the shared folders and projects the
caller belongs to, plus the read-only skills and docs trees.

The root is virtual, and that is the design. Anchoring at `~` is wrong:
the explorer reads host-side, while `shared/`, `projects/`, `skills/` and
`docs/` are bind mounts inside the container — a page rooted at the home
would show less than the user has with no way to reach the rest, and on
native Linux would show Docker's empty mountpoint stubs, a door that
appears to work and leads nowhere. So level 0 is a synthetic list from the
new `GET /api/files/roots`, serialized from the caller's `UserFs` plus the
two virtual memory roots. It sends `kind`, never a label: labels are copy
and get translated.

`GET /api/files/dir` now answers `{ path, can_write, entries }`, and a
memory path is classified before `resolve_view_path` (which refuses one)
and listed from `memory_docs`: one level derived from the flat key space
by the pure `memory_docs::immediate_children`, over a single query whose
unslashed prefix also spots an exact note as "not a directory". Memory is
read-only from the page — every writer routes through `resolve_view_path`,
and `shared-memory/*` is `@fs_write require` for the agent, so a button
that walks past that rule is a decision of its own.

The explorer moves out of projects into `shared/file-explorer.js`, taking
`root` + `rootLabel` and reading `can_write` from the listing rather than
from its host: writability changes per branch and comes from the same
`UserFs::can_write_to` the server rejects writes with, so the buttons
offered and the writes accepted cannot disagree. Deep-linking needed it
steerable without a two-way binding, hence `rel` in and
`explorer-navigate` out — the event fires only for a click, never for a
`rel` the host set, so echoing it back is a no-op.

The URL carries the agent path of the open folder in one parameter, the
same vocabulary the assistant uses, so a link is shareable and pasteable
into a conversation; which root it belongs to is derived, not stored.

docs/: a new files.md, plus two pages this made false — shared-folders.md
claimed in three places that a shared folder has no explorer, and
memory.md never said a user can now read their own notes.

web/components/sidebar.js

@@ -23,6 +23,10 @@ const NAV = [
   { id: 'inbox',          group: 'workspace',  priority: 20, icon: 'inbox',           labelKey: 'nav.inbox' },
   { id: 'dashboard',      group: 'workspace',  priority: 30, icon: 'speedometer2',    labelKey: 'nav.dashboard' },
   { id: 'projects',       group: 'workspace',  priority: 40, icon: 'kanban',          labelKey: 'nav.projects' },
+  // Everything this person can reach on disk, plus their two memory stores.
+  // Distinct from "Shared folders" below, which is the admin's CRUD *over* one
+  // kind of them — hence the two different words in the copy.
+  { id: 'files',          group: 'workspace',  priority: 45, icon: 'folder2-open',    labelKey: 'nav.files' },
   { id: 'tasks',          group: 'workspace',  priority: 50, icon: 'lightning-charge',labelKey: 'nav.tasks' },
   // Shared folders is admin-managed but *content*, so it lives with the daily
   // items, not buried in Configuration — the link stays admin-gated per-entry.
@@ -248,7 +252,7 @@ export class AppSidebar extends I18nMixin(LightElement) {
     // `connector` (singular) is the per-connector detail page, `connectors` the list.
     // `plugin-catalog` is the pre-merge hash of what is now `#plugins`.
     const page = segment === 'plugin-catalog' ? 'plugins' : segment;
-    return ['inbox', 'dashboard', 'tasks', 'projects', 'models', 'providers', 'approval', 'agents', 'users', 'roles', 'shared-folders', 'connectors', 'connector', 'plugins', 'plugin-detail', 'marketplace', 'profile', 'config', 'llm-requests', 'session', 'system-agents', 'file_viewer', 'tool_detail'].includes(page) ? page : 'home';
+    return ['inbox', 'dashboard', 'tasks', 'projects', 'files', 'models', 'providers', 'approval', 'agents', 'users', 'roles', 'shared-folders', 'connectors', 'connector', 'plugins', 'plugin-detail', 'marketplace', 'profile', 'config', 'llm-requests', 'session', 'system-agents', 'file_viewer', 'tool_detail'].includes(page) ? page : 'home';
   }
 
   _tasksSectionFromHash() {