[Presets] Support for dstack preset push and dstack preset pull

[peterschmidt85]

Push and pull

A preset created on one machine can now be used on another. Push it to the registry:

$ dstack preset push qwen38-27b-mi300x main/qwen38-27b-mi300x
OK

Then, on any other machine, pull it from the registry and export it to a service configuration:

$ dstack preset pull main/qwen38-27b-mi300x
OK

$ dstack preset export main/qwen38-27b-mi300x -f qwen38.dstack.yml
OK

$ dstack apply -f qwen38.dstack.yml

export writes the preset's patch files next to the configuration, so the service is applied
exactly as it was verified.

Push shares the verified service, its benchmark, and the hardware it was verified on. The
configuration, prompt, and trials that produced it stay on the machine that created it.

A pulled preset is used like any other, and is named <project>/<name>, which can never clash
with a preset of your own:

$ dstack preset list -a
 NAME                      ID                                    BASE              CONSTRAINTS      BENCHMARK                             STATUS           SUBMITTED
 main/qwen38-27b-mi300x    e7c8b170-8ca6-41cc-bfa9-ed1ba71c8c88  Qwen/Qwen3.8-27B  io=10K/1.5K c=4  tps/user=138 ttft=852ms ctx=1M        pulled           11 mins ago
 qwen38-27b-mi300x-crack2  6900d9d7                              Qwen/Qwen3.8-27B  io=10K/1.5K c=4  tps/user=138 ttft=852ms ctx=1M  ████  verified (4/15)  1 week ago

Its status is pulled, in the table above and in dstack preset get --json.

Names

A name is a moving reference, as a Docker tag is. Pushing one that already exists transfers it to
the new preset, and the superseded preset keeps existing without a name, reached as
<project>/<id>, which pull also accepts. A preset pulled that way lands untagged, so it never
shadows the one the name points at. Deleting a preset releases its name rather than handing it
back to an older one.

Registry

The registry is part of the dstack server. On dstack Sky, that is https://sky.dstack.ai. Push and
pull require membership in the project. If the server has no registry, both say so.

The server comes from the project's entry in ~/.dstack/config.yml. A project that is not there
falls back to dstack Sky; DSTACK_NO_SKY_FALLBACK turns the fallback off.

Note

The fallback is exactly the one dstack login applies.

UI

Presets are listed with filters for project, user, and base model. A preset opens on what it was
verified on, the benchmark and the constraints it holds under, and the commands to pull, export,
and apply it. The pages are Sky-only, gated as Billing is.

Also here

• dstack preset export no longer fails with IsADirectoryError when the preset mounts a
  directory in files.
• Presets can be the target of events, and list_events filters by them, so a server with a
  registry can record who pushed what. The events table shows them and filters by them.
• Events moves down the sidebar to sit next to Projects.

Breaking changes

• dstack preset get --json reports the served model repository as repo instead of model, so
  base (the model family), repo (what the service loads), and service.model (what the
  endpoint serves it as) are now distinct.

Backward compatibility

• Presets created by earlier versions are upgraded when read.

Note

The registry that push and pull talk to is implemented separately and is not part of this
PR.

[jvstme]

So if I have several Sky users, the CLI will select a random one?

This might be unexpected — that random user may have insufficient permissions, or it may be a user that I just wouldn't want to be used and recorded as actor in events.

Long-term, this could be solved by redesigning CLI authorization. Short term — by not falling back to Sky if it's not clear which user to choose (if there are more than one)?