GitHub actions job "docker-ymax" has some flaws

[gibson042]

In workflow Build release Docker Images, there are some problems with job "docker-ymax":

• Job outputs tag and tags refer to a nonexistent "docker-tags" step (such a step does exist in job "docker-sdk", from which "docker-ymax" was presumably copied).
• The job outputs Docker images with primary tags like "${TIMESTAMP}-${SHORT_SHA}", which are too easily confusable with those from job "docker-sdk"—and actually seem to collide with those from the other job (e.g., https://github.com/Agoric/agoric-sdk/pkgs/container/agoric-sdk/682587611 and https://github.com/Agoric/agoric-sdk/pkgs/container/agoric-sdk/682591145 were published at about the same time, but the latter has tag "20260212054536-754698" while the former lacks any tag of that format, implying that it originally applied but was moved).
• Multi-arch artifacts from the job (such as 20260210200126-fbb1e8) lack package-level metadata, most obviously org.opencontainers.image.description (which I think must be set through annotations, cf. https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#labelling-container-images ). Note that this also affects images from other jobs as well.

The second problem is obviously the most severe, and I think would be best addressed by publishing ymax images into a new package rather than having them share agoric-sdk and updating job "deploy-ymax0-planner" and workflow deploy-ymax1-planner.yml accordingly (along with anything else as relevant). Note that job "docker-solo" already publishes into distinct package cosmic-swingset-solo, so we'd just need another one.

It would also be nice if the intended-to-be-stable tags theirselves were prefixed, e.g. "ymax-planner-20260212054536-754698" rather than just "20260212054536-754698".