[FEATURE] Provisioner registry and install layer for Score (score-hub)

Detailed description

Installing a community provisioner today is done by copy-pasting a raw GitHub URL:

score-k8s init --provisioners \
  https://raw.githubusercontent.com/score-spec/community-provisioners/refs/heads/main/dapr-pubsub/score-k8s/10-redis-dapr-pubsub.provisioners.yaml

That's 140+ characters, it's platform-specific, there's no checksum, nothing is pinned, and there's no record of what was installed. As community-provisioners grows this gets worse.

I'd like to discuss adding a proper install layer so developers can do:

score-hub install dapr-pubsub --variant redis

Context

Provisioners are how platform engineers wire resources to Score workloads. Every developer hits the install step whenever they onboard to a new resource type. The raw URL workflow is the first impression and it's rough.

Specific problems right now:

• No discovery: you have to already know the URL or go searching on GitHub
• No variant selection: dapr-pubsub has a rabbitmq variant and a redis variant, you pick by editing the URL
• No integrity check: the URL can silently serve different content at different times
• No lock file: nothing records what was installed, at what commit, or with what checksum, so environments aren't reproducible
• No way to mix official and internal provisioners in the same workflow

I built a POC called score-hub-cli (https://github.com/ShantKhatri/score-hub-cli) to explore what this could look like.

Possible implementation

The core primitives any solution would need:

An index - a structured YAML describing available provisioners, variants, platforms, and checksums. Something like:

- name: dapr-pubsub
  category: messaging
  variants:
    - id: redis
      platforms:
        k8s:
          path: dapr-pubsub/score-k8s/10-redis-dapr-pubsub.provisioners.yaml
          checksum: "sha256:bd80a6bc..."
        compose:
          path: dapr-pubsub/score-compose/10-redis-dapr-pubsub.provisioners.yaml
          checksum: "sha256:8434fbfd..."

A lock file - .score-hub.lock committed to source control, pinning every installed provisioner to a specific version, commit, and checksum. Same idea as a go.sum or package-lock.json.

Platform auto-detection - inspect .score-k8s/ or .score-compose/ directories to figure out which Score platform is active so you don't have to specify it every time.

Additional information

POC: https://github.com/ShantKhatri/score-hub-cli (Go, Resolver interface abstraction, GitHub-backed index)

The POC currently indexes 11 provisioners from community-provisioners across 28 variants (messaging, networking, storage, compute, LLM, configuration).

Start with the score-hub-cli POC, especially its Resolver interface and GitHub-backed index, then compare it with the raw URL workflow described here. The issue is complete only when the project agrees on scope and an implementation path for discovery, variants, integrity checks, lock files, and platform detection.