fix: two skills taught resources the platform does not have

[stxkxs]

fab's skills are the regeneration source — read into the preamble of every factory session, shaping every artifact an agent produces. A skill naming something nonexistent doesn't just mislead a reader; it re-emits the defect into the next generated tenant.

Two instances, both live.

eks-agent-platform-curation.md — a deleted CRD, taught as current

Listed BatchJob in the agents.nanohype.dev group and defined it as "a Bedrock batch inference run over an S3 prefix". No control plane serves that kind. An agent curating against this skill authors a CR the API server rejects.

kubernetes-engineering.md — a namespace nothing creates

Taught a NetworkPolicy whose ingress admits the observability namespace. The observability addons land in monitoring — which is what the Kyverno exclusion lists and the operator both name. Verified: no ApplicationSet places anything in observability.

A policy generated from this example admits traffic from a namespace that does not exist, so the rule matches nothing and the ingress it was meant to permit is silently dropped. Renders clean, lints clean, passes every policy gate.

This is the same defect already fixed at four other sites — and this file is where those four were generated from, so leaving it would have restored them on the next generation.

What is deliberately not fixed here

There is no gate over fab/skills, and these are the second and third instances found in one campaign. The obstacle is real rather than an oversight:

fab vendors two nanohype standards (language-toolchain, llm-policy) and neither enumerates the platform's CRD kinds. platform-tenant-contract.json has no machine-readable kind list either. So a check needs a new vendoring channel for the kind list, not a regex.

Filed with that scope rather than approximated with a weaker check that would pass on the next instance.

npm run lint clean; 502 tests across 33 files pass.