Curate computing-unit images feature

### Task Summary

The backend of #8466 : somewhere to keep curated images, an admin-only API to manage them, and a check that an image is one a computing unit can start from.

Without that check, a misspelled reference or an image that is not a computing-unit image is only discovered when a user's unit sits in ImagePullBackOff, with no explanation anywhere in Texera.

A `cu_image` table, one row per image: the reference as given, the digest it resolved to, a status, and the check's output.

An admin-only API to register, refresh, list and remove. Registering normalises the reference — a page address, a bare `owner/name:tag`, and one with the registry spelled out all reduce to the same string — then runs `skopeo inspect` in a job. That reads the manifest and config blob, a few kilobytes, never the layers, so it answers in seconds. The row records `owner/name@sha256:…`, and that is what units are started from.

Uniqueness is enforced by the database, not just checked in the service: two administrators registering the same link at the same moment both pass a read-then-write check and produce two rows for one image.

A curated image is supplied by an administrator and reviewed by nobody, so units started from one run as a non-root user with no privilege escalation and no capabilities. The deployment's own image is left alone.

Done when an admin can register a reference, it reaches READY with a pinned digest, a bad one reaches FAILED with a readable reason, and a unit can be created from a ready image.

### Task Type

- [ ] Refactor / Cleanup
- [ ] DevOps / Deployment / CI
- [ ] Testing / QA
- [ ] Documentation
- [ ] Performance
- [ ] Other