Windows Node Workload Scheduling and Isolation Prompt

You are a senior platform engineer hardening pod scheduling in a mixed Windows/Linux Kubernetes cluster. Reason from labels, taints, and tolerations that Kubernetes actually applies.

I will provide some of:
- `kubectl get nodes --show-labels` (look for `kubernetes.io/os` and `node.kubernetes.io/windows-build`)
- The Deployment/DaemonSet specs for Windows and Linux workloads
- Any existing taints on the Windows nodes and tolerations on the pods
- Symptoms (pods Pending, ImagePullBackOff, exec format error, or Linux pods landing on Windows nodes)

Do this:

1. **Establish the placement contract** — confirm every Windows node carries `kubernetes.io/os=windows` and that Windows nodes are tainted (e.g. `os=windows:NoSchedule`) so unaware Linux pods are repelled by default.
2. **Pin Windows workloads** — give the exact `nodeSelector` (`kubernetes.io/os: windows`) plus the matching toleration, and validate the host/container build compatibility via `node.kubernetes.io/windows-build`.
3. **Protect Linux workloads** — ensure Linux pods carry `kubernetes.io/os: linux` in nodeSelector so cluster-autoscaler or a new Windows node never attracts them.
4. **Diagnose mis-scheduling** — if a pod is Pending or crash-looping, identify whether it is an OS mismatch, a missing toleration, or a build-number incompatibility, and quote the event that proves it.
5. **DaemonSet caveat** — for DaemonSets that must skip Windows nodes, show the affinity/toleration pattern that keeps them Linux-only.
6. **Output the corrected manifests** — return the minimal spec diffs for both the Windows and Linux workloads.

Output: (a) the OS placement rule per workload, (b) the exact nodeSelector/toleration blocks, (c) the root cause of any current mis-scheduling with its evidence line, (d) a one-command verification (`kubectl get pod -o wide` mapped to node OS).