Decide whether generators moves to Astera-org before consumers vendor from it

[ealt]

The question

This repo is ealt/generators. Astera-org/generators does not exist.

simplexity (an Astera-org repo) now references this repo in several places as the source consumers
should vendor generative processes from:

• a PendingDeprecationWarning message emitted at runtime from
  simplexity.generative_processes, which every teammate importing that package will see
• simplexity/run_management/protocols.py module docstring
• docs/generators_migration.md, the consumer-facing migration guide
• docs/design/generators_instantiation.md
• the README of the vendored copy checked into simplexity's test suite

All of those point at https://github.com/ealt/generators, because that is what resolves. (I had
originally written Astera-org/generators on the assumption it was org-hosted; corrected once it
404'd.)

Why it is worth settling before consumers vendor in earnest

If this becomes the team's canonical source for generative-process code — which is what the
deprecation makes it — then a shared Astera repo whose deprecation notice directs people to an
individual account is awkward, and more practically:

• Vendored copies record their upstream commit so they can be diffed later to pick up
  improvements. If the repo moves, every recorded provenance pointer needs updating, and the more
  copies exist the more expensive that is.
• The URL is baked into a runtime warning string, so a move means a simplexity release to change
  it.
• USAGE.md frames this as the mechanism for a research team to decouple ("The team shares the spec
  and the starting points, not a merge queue"), which reads as org-level infrastructure.

Moving early is cheap; moving after several projects have vendored from it is not.

Options

1. Transfer to Astera-org/generators now, before the migration guide gets used. GitHub redirects
   the old URL, so existing references keep working.
2. Stay at ealt/generators deliberately, and leave simplexity's references as they are. Fine if
   this is meant to remain a personal reference implementation rather than team infrastructure — but
   then the deprecation framing in simplexity probably needs softening.

No action needed in simplexity either way right now; its references are correct as of today.