Fix(assets): attached files land in assets/, and uploads are no longer corrupted

[adibhanna]

Two bugs in the same Add image / attach button, one per vault kind. Closes #40.

Local vault: the file went to the vault root

importDroppedFile asked for a unique name in '', the vault root, wrote the file there, and hand-built the link as '../'.repeat(depth) + filename, so a note in a folder got ![name](<../name.jpg>).

Paste already wrote to assets/, and so did the cloud vault, which is why it looked like paste and attach were different features. Reported on Discord by xenin, whose shape_image 18.jpg was the seventeenth name collision in their vault root.

Desktop had this exact bug and fixed it in ZenNotes#377; the port here was missed.

Now: assets/, linked by vault-relative path, an image as ![[assets/pic.jpg]], matching paste and the cloud vault.

Self-hosted vault: every upload arrived corrupt (#40)

The upload hand-built its multipart body as one string and marked the file part Content-Transfer-Encoding: base64. That header is a MIME construct: RFC 7578 dropped it from multipart/form-data, and Go's mime/multipart ignores it. The server wrote the base64 text to disk as the file's bytes, so the attachment landed in assets/ with the right name, about a third larger than the original, and unreadable by anything, which matches the report exactly, including that it opened as nothing straight from the Assets folder.

The bytes must stay base64 to cross the native bridge, since a CapacitorHttp string body is written out as UTF-8 and mangles anything above 0x7F. dataType: 'formData' is the supported route: both native layers decode a base64File entry and write the raw bytes into the part (Android CapacitorHttpUrlConnection.writeFormDataRequestBody, iOS CapacitorUrlRequest.getRequestDataFromFormData). The sibling direct-object upload already used the same mechanism with dataType: 'file'.

Proven against the real Go server

Both body shapes posted to a running server with the same PNG:

body	stored	begins	matches original
old	638,352 bytes	iVBORw0K (base64 text)	no
new	478,762 bytes	\x89PNG	yes, identical sha256

The old file is exactly 4/3 the original, the signature of base64 inflation.

Verification

• npm test: 28 passed
• npm run typecheck: passed
• npm run build and npm run sync: passed
• Native Android: testDebugUnitTest, lintDebug, and assembleDebug passed (601 Gradle tasks)
• Matching iOS changes: Fix(assets): attached files land in assets/, and uploads are no longer corrupted zennotesios#15
• Matching desktop/server changes: 2.40.0: the Linux updater installs the right package, and every device links attachments the same way zennotes#699

Files already sitting in a vault root do not move themselves, and attachments already uploaded corrupt stay corrupt and need re-adding.