Upload one part of a larger file (upload_id, part_index in body)

Upload a file too big for one write_file call, in parts: send each part with the same upload_id and a 0-based part_index (each part at most max_write_file_bytes decoded - 4 MiB by default - base64 for binary), then call commit_file_parts once with the path, part_count and the whole file's sha256. Parts land as files under ~/.givemeanode/uploads/<upload_id>/ on the node's own disk: nothing is stored server-side, and a stopped node keeps them. Returns {written, upload_id, part_index, bytes_written, sha256, sha256_verified, upload_bytes}; the part is hashed on the node before it lands, exactly like write_file, and upload_bytes is the upload's running total. Re-sending a part_index overwrites that part, so a retry after a lost answer is safe; choose upload_id from the file (its sha256, or the first 16 hex chars) so a retried upload resumes instead of starting over. Ceilings: max_chunked_write_parts parts per upload and max_chunked_write_bytes for the whole file (list_limits; 256 parts and 256 MiB by default) - a bigger file goes through storage (autor storage cp, then import_data) or is pulled from inside the node. Calling this on a stopped node wakes it, exactly like write_file, and THE PART DOES NOT LAND on the queued/waking answers (written:false): re-send it once the node is running; to push many parts, wake the node, then hold_node, then send. Each part opens a billed session on the node's mission like any other exec. The answer's timing_ms says where a slow call spent its time: server is our whole handling of the call and exec the node leg, and a part lands in well under a second. Time past that is your client producing the content, so send text as utf8 (base64 only for binary) and use the biggest part your client allows. NOT for secrets (run_command's env). From a shell, autor cp takes this path by itself when a file is over the single-call cap.