generic-packs: support oci:// references via install-oci-pack

[ChipWolf]

Adds OCI registry support to GENERIC_PACKS. An entry that resolves to oci://… (tag or @sha256: digest) is pulled with mc-image-helper install-oci-pack; everything else keeps the existing isURL→local behaviour. Purely additive — oci:// is required, so a bare ghcr.io/… is still treated as a local path.

OCI, URL, and local entries can be mixed in one list and apply in declared order. The OCI branch appends the helper's layer paths to packFiles[] in manifest order, so the existing extract, GENERIC_PACKS_DISABLE_MODS, manifest-diff, and sha1sum checksum pipeline is unchanged.

Design notes

• Single list, not a new GENERIC_PACKS_OCI var: nothing new to document, preserves cross-scheme ordering, and reuses PREFIX/SUFFIX/DISABLE_MODS and the update/checksum machinery.
• One new var: GENERIC_PACKS_OCI_AUTH_FILE → --auth-file (passed only when set; otherwise the helper's ~/.config/containers/auth.json → ~/.docker/config.json fallback, else anonymous).
• Validation is left to the helper: called without --artifact-type/--layer-media-type, so it enforces the modpack artifact + layer media types and rejects non-modpack refs before anything touches /data.
• --output-directory /data/packs/oci with --filename-strategy digest (fixed): content-addressed cache, so a base layer shared between packs is fetched once.

Helper dependency: install-oci-pack (helper master). The image already pins MC_HELPER_VERSION=1.61.1, which includes it — no bump needed.

Docs: new "Generic packs from an OCI registry" section in docs/mods-and-plugins/index.md.

Test: tests/setuponlytests/generic-packs-oci pulls two demo packs that share a base layer (gated behind EXTENDED_TESTS, since it needs anonymous ghcr.io egress).

Refs #4038

[ChipWolf]

@itzg I suggest before merging that I create a template repo for generating these OCI artefacts and you create a repo under your GitHub account that can be used in the docs examples and the tests rather than using my oci-modpack-demo repo

I'll work on that if you reckon that's a good move

[itzg]

@itzg I suggest before merging that I create a template repo for generating these OCI artefacts and you create a repo under your GitHub account that can be used in the docs examples and the tests rather than using my oci-modpack-demo repo

I'll work on that if you reckon that's a good move

That would be fantastic.

[itzg]

The design looks great. I'll try to get to the code review ASAP.

[ChipWolf]

@itzg

The design looks great. I'll try to get to the code review ASAP.

Thanks!

Here it is https://github.com/ChipWolf/oci-modpack-template

If you're happy with that, feel free to clone, change the remote, and push to your own account

[itzg]

@ChipWolf , I really like the styling of this diagram. What did you use to create it? Actually all the diagrams.

[ChipWolf]

@ChipWolf , I really like the styling of this diagram. What did you use to create it?

Fable 5

[itzg]

It's forked https://github.com/itzg/oci-modpack-template ...or did you think a clone-and-push was better?

[itzg]

BTW I'm very impressed by how thorough you were with the template repo!

[itzg]

Looks great. Mark it ready when you're ready...and ping me please since apparently Github doesn't notify when a PR goes to ready.

[ChipWolf]

It's forked https://github.com/itzg/oci-modpack-template ...or did you think a clone-and-push was better?

Fork is fine, are actions enabled & has it released the artifacts? I'll need them available in your ghcr for the test suite here (see step 5 in the readme also)

[itzg]

Ah, I didn't follow all of your setup instructions 😉 With actions enabled it does indeed push the artifacts.

[ChipWolf]

pinging as requested @itzg tyvm

[itzg]

Fantastic!