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/projects/project-board.js

@@ -1,11 +1,11 @@
 import { html, nothing } from 'lit';
 import { LightElement } from '../../lib/base.js';
 import { t }            from '../../lib/i18n.js';
-import { ProjectFilesPanel } from './project-files.js';
+import '../shared/file-explorer.js';
 
-/// A project's detail page: header + description, then two tabs — **Files** (a
-/// live explorer over the project folder, `<project-files-panel>`) and
-/// **Sharing** (member picker with read/write, mirroring the shared-folders UI).
+/// A project's detail page: header + description, then two tabs — **Files** (the
+/// shared `<file-explorer>`, pointed at the project folder) and **Sharing**
+/// (member picker with read/write, mirroring the shared-folders UI).
 export class ProjectBoardSection extends LightElement {
   static properties = {
     _project:  { state: true },
@@ -276,13 +276,11 @@ export class ProjectBoardSection extends LightElement {
         ${this._renderTabs()}
 
         <div class="p-3">
-          <project-files-panel .project=${this._project}
-            style=${this._tab === 'files' ? '' : 'display:none'}></project-files-panel>
+          <file-explorer .root=${this._project.root_path ?? ''}
+            style=${this._tab === 'files' ? '' : 'display:none'}></file-explorer>
           ${this._tab === 'sharing' ? this._renderSharePanel() : nothing}
         </div>
       </div>
     `;
   }
 }
-
-customElements.define('project-files-panel', ProjectFilesPanel);