[jcbrand]

Copying a folder in a file manager (e.g. GNOME Files) and pasting it into the chat composer tried to upload it, which fails with "Sorry, looks like file upload is not supported by your server." (or a failed upload on servers that support it). Dropping a folder did the same.

Chromium exposes such a folder as a typeless File whose size is the directory's size on disk (4096 bytes here), so it can't be told apart by size or type. It can't be read, though. The upload paths now check this before uploading anything: sendFiles in headless (chat and MUC, however the file was added: paste, drop or the attachment menu) and uploadFile (the Social composer). A file that is empty, a folder, or no longer readable (e.g. deleted after it was copied) isn't uploaded, and the user is told why:

• in chat, an ephemeral error message, like the existing one for files that are too large;
• in Social, the usual "Sorry, could not upload …" toast.

The Social composer also gains a drop handler, so files dropped onto it are uploaded just like pasted ones. Previously only pasting was handled there.

Inserting the folder's path as text instead was considered but left out: Chromium hides that text from scripts, and recovering it needed a hidden "paste bin" textarea in the shared editor, too much complexity for a niche case. Copying the location with Ctrl+L in Files gives plain text, which already pastes fine.

The read check was verified live in Brave against Prosody with a real GNOME Files copy: the folder fails to read, a copied file reads fine.