Pin website.change with the organic system

[demegire]

What and why

Since v6, the organic system's technical and delivery steps run website.change (organic_system.WEBSITE_STEPS), but PARENT_CHILD_KEYS never pinned it with the system's revision. Production's registry hid the gap: it builds up over time, and earlier commits already held workflows/website.change.json.

On staging's fresh registry, Claw Messenger's first organic system run (8710f7ff) failed in organic_system_prepare. code.storage returned 404 for workflows/website.change.json at the system's revision. A new self-hosted install would hit the same failure. In production it also means organic runs read whatever website.change happened to be in the registry at that commit, not one deliberately pinned with the system.

Verification

• test_the_organic_system_pins_every_workflow_its_prepare_step_reads (new): every key the prepare step reads (steps, website steps, measurement steps, refresh) is in pinned_children.
• The first-sync test now checks the website and measurement children's files at the parent's first revision too.
• Both fail without the fix and pass with it. Organic system and onboarding tests pass.

Tested on staging

Deployed to staging by pushing to staging (deploy-staging). I'll retry Claw Messenger's organic traffic system there and update this PR with the result.

Notes

On merge, the catalog sync publishes a new revision of organic.traffic_system that includes website.change. Runs and schedules already pinned to the old revision keep it.

🤖 Generated with Claude Code

[demegire]

Tested on staging: with this branch deployed (deploy-staging run 38411751299), Claw Messenger's organic traffic system (run d4e796d7) gets past organic_system_prepare. The audit and keyword-plan children are running, and the step list shows website.change for technical and delivery. On the previous build, run 8710f7ff failed in prepare with a code.storage 404 for workflows/website.change.json.