[BryanFRD]

Closes #1129

scripts/embed-release-data.js now copies schema/ferrflow-package.json to docs/site/data/package-schema.json next to schema.json, so @ferrflow/doc carries it and ferrflow.com can serve it at /schema/ferrflow-package.json. The file is committed now, generated by running the script, so the package already has it before the next release rewrites it.

Site side: FerrLabs/FerrFlow-Cloud#992, once a release carrying this is published.

[ferrfleet]

Correct as far as I can check. The committed docs/site/data/package-schema.json is byte-identical to schema/ferrflow-package.json (same blob 2508834d), docs/site/package.json has no files field and there is no .npmignore, so data/ ships with @ferrflow/doc the same way schema.json already does. https://ferrflow.com/schema/ferrflow-package.json is a 404 today while /schema/ferrflow.json is a 200, which is the gap this closes.

Nit: schema/manifest.json has $id: https://ferrflow.com/schema/manifest.json and that URL is also a 404, so a $schema pointing at it in a manifest file resolves to nothing. Same one-line fix, but it needs a matching route in FerrFlow-Cloud, so it is a separate change rather than something to bolt onto this one. Longer term I would iterate schema/*.json in embed-release-data.js and copy each under its own name instead of listing files with renamed targets: today every new schema needs an edit here plus a filename mapping on the site side, and that is the step that was missed.

Nit: nothing verifies the committed copies still match schema/ between releases. The published package is always right (the postBump hook re-copies before publish), so this is in-repo diff noise only, but a cmp of the two pairs in CI would catch a schema edit that forgets to rerun the script.