Add a deploy-on-Hugging-Face-Spaces option for users without an LS instance

[davanstrien]

What this adds

A references/deploy_on_spaces.md guide that stands up a persistent Label Studio instance on a Hugging Face Space in three hf CLI commands (create a bucket → duplicate the official LS Space → factory reboot), plus the credential and lock-down steps to make it usable from this skill.

It fills the one gap this skill has no answer for: the validate_config.py --server and push_config.py steps need a reachable instance, and the skill doesn't help you create one. It's offered as one convenient option alongside the standard local / Docker / self-hosted / Enterprise installs — not as a new default.

Diff is reference-only: one new reference doc, a pointer + description tweak in SKILL.md, and a sibling subsection in README.md next to the existing local-install instructions. No new scripts, no new dependencies, no change to the existing auth model.

Why

Following a 2026-05-27 sync (Daniel / Hugging Face ↔ Micaela / HumanSignal): the idea is a combined deploy + configure surface — "no Label Studio instance yet → deploy" and "have one → configure" in the same skill. This draft is the deploy half, kept minimal so we can shape it together.

Opening as a draft — discussion anchor

Marking this draft deliberately: it's a concrete place to point at while we work through the threads below. Happy to take it in whatever direction fits the skill's conventions.

1. Modernize the skill's auth (directly relevant to this diff)

The skill authenticates with a legacy token (LABEL_STUDIO_API_KEY, sent as Authorization: Token …). Modern Label Studio organizations disable legacy tokens by default — you hit 401 — legacy token authentication has been disabled for this organization. The new deploy doc has to flag this in its credentials section, which makes the gap visible.

Worth discussing whether the skill (and validate_config.py / push_config.py) should move to the modern Personal Access Token flow (refresh → short-lived access token via POST /api/token/refresh/), or the modern label_studio_sdk.LabelStudio client that accepts PATs. Happy to follow up with a PR for that if you agree on the direction.

2. Broader threads from the sync (not part of this diff)

Listing so this PR can double as a discussion home:

• Modern-auth path for the example ML backends' webhook/train flow — the _get_tasks/fit path in several label-studio-ml-backend examples constructs the legacy Client, so auto-train 401s against modern-auth instances; naive per-webhook refresh also trips a 429 (needs token caching). Is there an official correct pattern?
• Prediction-refresh-after-train in active-learning loops — LS caches predictions per task, so already-prelabeled tasks don't refresh after fit(). Sanctioned way for a backend to refresh predictions post-train?
• Model-crossover (zero-shot foundation → fine-tuned small) as labeled data accumulates — any official pattern for swapping the wired backend mid-experiment?

[davanstrien]

cc @micaelakaplan — opening this as a draft per our 2026-05-27 sync, as a concrete place to anchor the combined deploy + configure direction. Kept it deliberately minimal (one new reference doc + small SKILL.md/README tweaks, no scripts/deps), and framed HF Spaces as one option rather than a default so it fits alongside the standard installs.

The thing I'd most value your read on is the legacy → PAT auth point in the description — the deploy doc surfaces that modern LS orgs disable legacy tokens by default, which affects the bundled scripts too. Happy to follow up with a separate PR for that (and to take this draft in whatever direction best fits the skill's conventions). No rush.