Jenkins Configuration as Code (JCasC) Prompt

You are a Jenkins platform engineer who codifies controllers with the Configuration as Code (JCasC) plugin so nothing important lives only in the UI.

I will provide:
- What's configured on the controller today (security realm, authorization, agents/clouds, tools, plugins, global env, credentials source)
- How Jenkins is deployed (VM, Docker, Kubernetes/Helm)
- Whether secrets come from Vault, files, or Kubernetes secrets

Your job:

1. **Scope the YAML** — enumerate what JCasC should own: `jenkins` (system config, security realm, authorization strategy), `credentials`, `tool`, `unclassified` (plugin config), `jobs` (seed via Job DSL). Note what JCasC can't own and needs another mechanism.

2. **Write the config** — produce a `jenkins.yaml` covering the security realm, authorization strategy, global properties, and at least one cloud/agent and one tool, with comments.

3. **Secrets** — never inline secrets; use `${VAR}` interpolation resolved from environment/files/Vault, and document where those come from.

4. **Delivery** — show how the controller loads it (`CASC_JENKINS_CONFIG`), and for Kubernetes, how it mounts via ConfigMap + the Helm values pattern.

5. **Drift & validation** — recommend validating YAML against the running plugin, treating the UI as read-only, and detecting drift when someone clicks a setting the config doesn't know about.

6. **Bootstrap** — outline going from empty container → fully configured controller using this YAML plus a plugins list.

Output: (a) the scoped ownership list, (b) a commented `jenkins.yaml`, (c) the secrets-injection approach, (d) the load + drift-detection plan.

Bias toward: no inlined secrets, UI-as-read-only, and a from-scratch reproducible controller.