feat(node): an upload lands in the folder it was sent to

There is no `uploads/` subdirectory any more, and the client names the folder
rather than the root.

It was the last of v5's quarantine — the per-user layer went on 2026-08-14 for
the same reason — and it goes on the same grounds: a folder appearing beside
the operator's library because somebody sent a file is the node deciding how
their disk is arranged. Somebody dropping a file into the folder they are
looking at expects it to be in that folder.

**What made the quarantine worth having was never the subdirectory.** It is the
filename allowlist, the size cap, the chunk ordering and the no-overwrite rule,
and all four are untouched: an existing file is never replaced, the second
sender of IMG_1234.jpg gets a free name, and the check still sits at the write.

Letting the client choose the destination is safe for one reason and only one:
it is resolved through `RootSet.resolve()`, which refuses `..`, absolute
segments and anything whose resolved form escapes its root, symlinks included.
A member answers "which of this group's folders", never "which path on the
operator's disk" — and the test that used to assert the node chose now asserts
that, with six shapes of escape.

`direct` goes with it. Its only job was to say "no subdirectory for this root",
which is now every root, and a config flag that does nothing is worse than none.

Chat's attachment folder finally does something: the directory the operator
picks in the Chat settings pane is where attachments are written, falling back
to the first writable root while they have not chosen one, or if the one they
chose has since been made read-only or ejected — a stale choice should not
become a refusal at send time.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011pvMdvLBG92jyhvD5pD6us

1 files changed, 12 insertions, 2 deletions

diff --git a/docs/meshbay-draft-v6.md b/docs/meshbay-draft-v6.md
index 4439cd1..28aea0c 100644
--- a/docs/meshbay-draft-v6.md
+++ b/docs/meshbay-draft-v6.md
@@ -74,12 +74,22 @@
 v5 confines uploads to `shared_root/uploads/` with a filename allowlist, no overwrite,
 chunk ordering and a size cap. All four protections stand. Two amendments:
 
-- There is no single `shared_root`. **Each root is read-only or read-write**, and the
-  quarantine lives inside whichever writable root the upload is addressed to. If that
+- There is no single `shared_root`. **Each root is read-only or read-write**, and an
+  upload goes to the folder the sender is looking at, inside a writable root. If that
   root is unavailable the upload fails with a stated reason and never falls back to
   another; if the group has no writable root, uploads are refused rather than guessed.
   (Amended 2026-09-06 — the original text designated *one* root as the upload
   destination, and the client named none. See `docs/refactor-groups.md` §1.1.)
+- **There is no `uploads/` quarantine directory any more** (2026-09-06). It was the
+  last of v5's, the per-user layer having gone on 2026-08-14, and it went for the same
+  reason: a folder appearing beside the operator's library because somebody sent a
+  file is the node deciding how their disk is arranged. **What made the quarantine
+  worth having was never the subdirectory** — it is the filename allowlist, the size
+  cap, the chunk ordering and the no-overwrite rule, and all four are unchanged.
+  The client now names the destination folder, which is safe for one reason and only
+  one: it is resolved through `RootSet.resolve()`, which refuses `..`, absolute
+  segments and anything escaping its root, symlinks included. A member answers "which
+  of this group's folders", never "which path on the operator's disk".
 - **The no-overwrite rule is unchanged and still holds on exFAT/NTFS.** An earlier
   draft claimed a string comparison let `README.TXT` land on `readme.txt` there. It does
   not: the check is `Path.exists()`, and `stat()` is itself case-insensitive on those