VastCreateInstanceRequest has no image_login: private registry images cannot be pulled #1

Summary

VastCreateInstanceRequest exposes no way to send Vast's image_login field, so an instance can only be created from an image that is anonymously pullable. Any private registry (ACR, ECR, GHCR, private Docker Hub) is out of reach, and the failure happens on the host after the rental is created.

Why it matters

Vast's create instance API accepts image_login ("Docker registry credentials if needed"), which the official CLI surfaces as --login "-u <user> -p <password> <registry>".

For anyone running proprietary workloads this is the difference between usable and not: the alternatives are publishing the image or not using the library. There's no workaround from OnStart either, since that runs inside the container — after the pull has already failed.

Where

src/VastAI.NET/Models/VastCreateInstanceRequest.cs — the request has Image, TemplateHashId, RuntimeType, Environment, OnStart, DiskGb, Label, CancelUnavailable, but no registry-credential field.

Suggested fix

Add an optional property serialized to image_login, passed through untouched:

/// <summary>Optional Docker registry credentials, in Vast's docker-login argument form
/// (e.g. "-u user -p password myregistry.example.com"). Required for a private image.</summary>
public string ImageLogin { get; set; } = "";

Additive and backwards-compatible — empty stays absent from the payload, so existing callers are unaffected.

A friendlier typed overload (registry/username/password formatted into the string by the client) would be nicer still, but the raw pass-through alone unblocks the scenario.

Version

VastAI.NET 1.0.3 (net10.0).

Note on a nearby doc nit

While reading the source: RuntimeType defaults to "ssh" and its doc comment says "This workflow uses SSH-capable containers." It took reading the source to establish that the property is freely settable — e.g. to "args" for entrypoint mode, which is what batch/run-to-completion workloads need. Worth a doc mention that non-SSH runtypes are supported, since the current wording reads as though the library is SSH-only.