docs(fork): upstream item — place a restore only on a worker whose CPU covers the snapshot's feature set (#37742 row 12)

[teemow]

Ledger only. Adds a section "Upstream items prepared without a carried patch" to FORK.md with the upstream-facing proposal for giantswarm/giantswarm#37742 row 12: place an actor's restore only on a worker whose CPU covers the snapshot's feature set.

Why now. On a Kubernetes 1.35 cluster whose WorkerPool nodes Karpenter provisions (2026-09-13), AMD c5a and Intel r6i nodes sat under one amd64 pool; the golden snapshot had been taken on an AMD worker and every restore on the Intel worker failed incompatible FeatureSet: missing features: cmp_legacy, cr8_legacy, sse4a, misalignsse, topoext, mmxext, fxsr_opt, retried in place every 30 s, the consumer's turn timing out. scheduling.Constraints knows the sandbox class, the label selectors, RequiredNodes and the limits — nothing about the CPU; a Worker reports no feature set.

The proposal (in the file): workers report their CPU feature set with their capacity; snapshots record the set they were taken with; Constraints.RequiredCPUFeatures derived from the snapshot the resume will load and enforced in Applies as a superset check, with a RESUMING actor released and rescheduled instead of retried on a worker that cannot load it; and a small first patch that classifies the runsc incompatible FeatureSet restore error as a placement failure (release, exclude the node for the actor, reschedule). Alignment: kagent-dev#19 extends the same Constraints.

Per the fork-first rule nothing is opened against upstream; row 12 of #37742 links here as the review item. The consumer-side pin (karpenter.k8s.aws/instance-cpu-manufacturer on the pool) is giantswarm/agent-platform#429.