feat(hub): drop files and folders onto Files to upload them

Into the folder on screen, under the Upload button's rule. A name already
there, or one the node would refuse, cancels the whole drop with a message.
Folders are recreated level by level; files go out a few at a time. The
in-flight upload guard is keyed by folder and name.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 12 insertions, 0 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 6b48300..2b6d1ac 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -1318,6 +1318,18 @@ whether to draw the Upload button and the chat paperclip, and changes are broadc
 to everyone connected. None of that is the control: a member on an old tab, or one
 speaking MNP directly, is refused by the node.
 
+**Files can be dropped onto the Files tab**, files and folders alike, under the
+Upload button's rule (a folder on screen, in a writable root, in a group — not in
+Search). A drop is decided whole before anything is sent: **a name already in the
+folder refuses it**, compared without case, because the node's no-overwrite rule
+would otherwise store a colliding file under a free name nobody asked for and
+refuse a colliding folder half-way through; and a name outside the filename
+allowlist refuses it too, from a client copy of the rule that a test holds to the
+node's answers. A folder is rebuilt one `dir_create` at a time, parents first, and
+its files are fed to the transfer store a few at a time so the member's queue
+(§5.5) never reaches its cap. None of this is a control — the node still enforces
+every rule above; it is what keeps a drop from ending in a partial copy.
+
 In a group with **no** writable root the interface says so plainly rather than
 picking one — a fallback that chooses whatever comes first only moves the failure
 to send time, where the person has already chosen the file.