Fetch private data onto the node via a stored connection

Fetch private data onto a RUNNING node using a stored org connection (list_connections): the platform exercises the access on the host - never in this chat, never inside the node - and the bytes appear at dest_path, owned by dev. Returns {import_id} immediately; poll get_import(node, import_id). source must sit inside the connection's scope: an s3:// url (object, or a prefix ending in "/" to import the subtree; on storage/<bucket> connections a non-slash source that names no exact object imports every key it prefixes, so a flat prefix splits into chunks: .../items/a, .../items/b) for s3 kinds - and on a storage/<bucket> connection, which already names its bucket, that url may also be written bucket-relative, "train/" meaning the same as "s3://<bucket>/train/" (the spelling autor storage and list_storage_objects speak); an s3-keys connection reaches a bucket we do not own, so there the full url is required. A repo id like "acme/corpus-v3" (optionally "repo@revision"; "datasets/owner/name" for HF dataset repos) for huggingface, "model:<id>" (its newest published version) or "version:<id>" (one specific version; the numeric ids from civitai.com URLs; where a version ships same-named file variants the primary one is taken, and with no primary they land disambiguated by file id) for civitai, an https url for https. A stopped node is a refusal and never a wake. A run_command wakes the node, and the wake bills. Import time is node time: you're billed while it streams, same as running curl yourself, and the transfer holds the node out of grace so the disk stays mounted. Sizes are bounded by the node's volume (the refusal names the numbers), and one import enumerates at most max_import_files objects (list_limits shows yours; the chunk form above is how a bigger prefix gets under it). Every call is recorded to your org's audit log (connection, node, source - never any credential).