Private SDKs support

The Kubernetes team needs a way to distribute internal Workshop SDKs across multiple repositories without making them publicly available. Currently, in-project SDKs work as a workaround but don't scale well. A private SDK mechanism in the SDK Store would solve this cleanly.
## Background
We maintain a shared set of AI agent configs (prompts, workflows, tool definitions) in [canonical/k8s-ai-agent-toolkit](https://github.com/canonical/k8s-ai-agent-toolkit). This repo is private since it references undisclosed repositories, internal processes, and pre-release tooling. The goal is to have a consistent AI-assisted development experience across all Kubernetes team workshops.
## Current Approach
I've packaged the toolkit as an in-project SDK following the [Workshop docs](https://ubuntu.com/workshop/docs/explanation/sdks/concepts/#in-project-sdks). This works but requires replicating the SDK definition into every repository that consumes it. We have 10+ active repos, so we need to implement additional automation to maintain this.

**What works:**
- SDK definition and hooks function correctly as in-project SDKs
- Configs are not exposed publicly since they live in private repos

**What doesn't work well:**
- No single source of truth. Updates require syncing to all repos
- Automation overhead (copy scripts, submodules, or CI steps) to keep repos in sync
- Easy to drift when someone forgets to pull the latest version
## Proposed Solution: Private SDKs
Publish SDKs to the SDK Store with restricted visibility. Same mechanics as public SDKs (channels, versioning, platform metadata) but access-controlled.

**Requirements from our side:**
- Restrict access to Canonical users (at minimum), ideally per-team or per-org
- Publish and update via `sdkcraft upload` the same way public SDKs work
- Consume via `sdk:` entries in `workshop.yaml` without special handling
- No changes to SDK definition format needed (visibility is a Store property, not a packaging one)

**Benefits:**
- Publish once, consume everywhere
- No sync scripts or submodules
- Sensitive references (internal repos, unreleased tooling) stay private
- Other teams with internal tooling SDKs get the same benefit