feat(addons): install development add-ons by tag, as backends do (#12883)

A development add-on entry now names a moving tag, sets mutable and has
no digest, the same shape a development backend entry has. A release
entry stays pinned by digest.

One helper, catalog.Pin, turns a mutable entry into a digest at install:
it resolves the tag, checks the digest form and builds the version from
the first 12 hex digits. The backend library installer and the add-on
installer both call it. The add-on installer then verifies the signature
against the resolved digest and records that digest in the receipt. Kind,
platform and install label checks stay in each caller.

The official index lists the development entries as <id>-development,
which the publish workflow already moves in its promote job. The catalog
command renders the development channel as mutable entries. The update
check reports no state for a mutable entry until it resolves the tag too.

Assisted-by: Claude:claude-sonnet-5-5 [Claude Code]

Signed-off-by: Ettore Di Giacinto <mudler@localai.io>
Co-authored-by: Ettore Di Giacinto <mudler@localai.io>

.github/workflows/addons-package.yml

@@ -18,7 +18,10 @@ name: 'add-on packages'
 # value of ADDON_OCI_REPOSITORY (the add-on registry organization). Each
 # add-on is a set of tags of that repository, prefixed with its id:
 # <id>-sha-<short sha> for a commit, <id>-<version> for a release and
-# <id>-development or <id>-latest for a channel alias. Signatures and digests
+# <id>-development or <id>-latest for a channel alias. The development alias is
+# the tag a development library entry names (mutable, no digest); the install
+# resolves it to a digest, as for a development backend, so it moves only in
+# the promote job below. Signatures and digests
 # are per image, so add-ons never collide. A publishing event fails for an
 # add-on until one of its platforms is enabled.
 #